How to win against AI threats the world has never seen before.
Zero Trust DNS (ZT DNS) re-imagines connectivity at the foundational level, creating a new security control exactly where the Internet needs it most.
This is the first of a three-part series. In Session 1: Concepts & Principles, we examine the purpose and core ideas behind Microsoft’s Zero Trust DNS (ZTDNS) and ADAMnetworks’ Don’t Talk to Strangers (DTTS).
Session Transcript
Francois: Hi guys. Thank you for joining us for this session: Zero Trust DNS and Don’t Talk to Strangers. This is the first session of a few. The big question is: why are we actually here? Why are we in this session? And David, I’ll let you jump in.
David: Hello, I’m David, founder and CEO of ADAMnetworks. About 10 years ago, we saw the writing on the wall that the bad guys can always outrun the good guys and always find new and innovative ways of doing bad things. This was kind of by design in a way that I’m sure we’ll get to talk about in these sessions. But keeping up with the bad guys was just something that we saw would not be possible, and so we had to rethink some things. That’s really how things got started.
Francois: Yeah. And Aditi, for you?
Aditi: Yeah, hi. I’m Aditi. I’m a product manager at Microsoft. I build the next generation of networking solutions for Windows. Particularly when I think about my role, when I am building the plumbing of the internet, I feel that it is my social responsibility to make sure that the solutions we build are safe, since it’s going to be used by billions of people in their work lives and in their personal lives. We cannot have such a foundational technology just be insecure.
Francois: Right. My name is Francois. I’m co-founder with David at ADAMnetworks. The reason why we’re doing these sessions and the reason why we are talking about this together is because we all have a common goal, and that’s ultimately to protect people. I think the core driver for me in this whole discussion is that technology, in the end, should serve people and not the other way around. I think we should just jump right in.
If you think about something so significant as the internet that has now become really a core of our lives—an integrated part of our lives—what we find if you look at any technology, really, is that it starts off first to work: you get stuff to work. Then you get it to be optimized, and only then do you move to a place where you think, “Okay, well, let’s get this thing secured.”
Let’s look at a car—automobiles—and how that came into our lives. First of all: let’s get this thing to work. There’s no horse in it anymore, there’s some sort of engine going, and great, we got this thing to work! Well, let’s get it to drive faster, cut corners better, and have better roadholding. Then people started dying, and vehicles started getting stolen. Now you move into a place where you say, “Oh, hold on. This design actually needs a canopy. It needs seat belts. It actually needs airbags. It needs ABS.” These are all things that came after the fact, after people started getting hurt by engaging with this technology.
So it’s really three phases: get stuff to work, then you move into getting it optimized, and only then do you move to, “Well, let’s get it secured.” It’s kind of like the internet is following the exact same recipe.
David, you as a veteran since the beginning—since the dawn of defending when the internet started coming into being—how does that apply from your point of view?
David: Well, you know what’s interesting, guys, is that the internet is as young as I am, or as old, depending on how you want to look at it. It was only designed—or thought of—a little over 50 years ago. Back in the ARPANET days, it was a military effort, not designed to be secure, but rather for it to be free of interference. It was designed to be able to route around any obstacle because, of course, the military places a very high level of importance associated with the ability to communicate.
That’s what’s still at the foundational layer of the IP protocol: how can it route around anything? And so then the bad guys started saying, “What? You can route around anything? Tell me more!” Right? And so that original design to this day is part of network connectivity. It follows that exact recipe that you described.
Francois: Yeah. Aditi?
Aditi: Yeah, I would say that one thing that has definitely become really clear in the past decade or more has been that topical, post facto security solutions that we usually see out there are not going to fix foundational problems. We have become really good at detecting threats after they have landed at least once. Once malware executes, we identify it and then we block it. After the data has been exfiltrated, we know, “Oh, this was the path used, so the next time around we are going to protect it.”
But what do we do with Patient Zero scenarios? In my opinion, the real question is: why was that connection allowed in the first place? Why was there one victim? Because with all of the new AI stuff coming around, it is going to be very easy to create unique attacks and create more of these Patient Zero scenarios. If we keep allowing those connections, then yeah, it’s really not going to be a very good place.
Francois: Yeah, and I think what you’re addressing here is what we generally refer to as the idea of true proactive security. I think we’ll do a session diving into that even more.
Coming back to what you’re addressing so clearly here: there has to be a security layer to the IP protocol. But how do you actually implement this now? The internet is already what the internet is; we can’t recall it and change it, right? What do we actually do? How do you change that connection that you’re saying should never have happened? How do you change that without saying, “Let’s Ctrl+Alt+Delete and redo the internet”?
That’s really the beginnings of a Zero Trust connectivity approach: to say, “Well, what if we could actually change it from the endpoint that’s connecting when that connection request takes place?” If somehow you could say no connection takes place unless, by some control surface, it should be allowed, then that connection can take place. Other than that, the connection is simply non-existent. How do we actually do this?
Aditi, how are you doing that from the Microsoft side?
Aditi: IP is basically, like you rightly mentioned, designed to work, but not to be secure. When you’re working at the IP layer, you don’t know exactly who you’re talking to. It’s just basically routing packets at that point without having any security component to it. There is no identity, there’s no authentication; it’s just doing some dumb routing to make sure you reach the destination in the least amount of time.
What we did at Microsoft was very much in line with what you just mentioned, Francois, about making sure that DNS is the root of trust. We enforce DNS resolution for every single connection that is trying to go out there. We block by default, like you mentioned, and only allow things that were allowed by DNS. Assuming that your DNS server already knows the identity of those IP addresses, it can connect a given IP address back to its domain name, which should give you some idea of what you’re trying to talk to as well. It is a place where already we have an industry applying policies where a given domain name is supposed to be allowed or not. We already do that today in Protective DNS.
So we at Microsoft are just trying to reuse all of that infrastructure and embed it into our solution that we are calling Zero Trust DNS, with exactly the principles that you mentioned.
Francois: David, you’ve used the word “porosity” a lot around here. Tell me about the porosity of the internet when it comes to DNS and IP.
David: Well, what’s interesting is that the IP layer was invented long before the Domain Name System was invented. In the early days, it was only IP addresses. It was exciting enough that one university campus could talk to another university campus by an IP address. But obviously that was not practical—certainly not practical for everyday normal people.
When the Domain Name System was invented, it was specifically to be a namespace so we could associate words that we as humans prefer to use over numbers when addressing. Because it came after the fact, we never really had this design at the outset. Communication directly by IP address remained an open channel for all of history. To this day, unless you are in a Zero Trust or “Don’t Talk to Strangers” environment, your direct IP-to-IP communication that doesn’t use DNS is still possible.
Francois: Mm-hmm.
David: And that is what the bad guys can easily weaponize.
Francois: Yeah. So even in the beginning of this, DNS was kind of a nice-to-have. There’s nothing that forces any connection to have to do that, and that’s really at the core of what we are busy addressing here. As we dive into this deeper, I hope that it’s going to be clear to everyone that’s watching this.
Of course, there are some legitimate connections that will function without DNS, as you mentioned, David. But of the total number of connections taking place these days, how many of them, in your experience, fall into that category?
David: Of all the connections that occur, the vast majority are for sure DNS-based because it’s easier for developers to write software. It’s more resilient, and it gives the hosting environment the flexibility to move from one cloud zone to another cloud zone just by changing IP addresses after the infrastructure is set up. For all kinds of reasons, it’s DNS-based.
There are some legacy and some legitimate speed-sensitive services that say, “You know what? The way we can speed things up is not to use DNS.” That’s a very small percentage—less than 1% of connections would fall into that category—but it does still happen.
Francois: Yeah. But that brings us to a place where we can say, “Hold on, maybe we can work with DNS. Maybe that’s something we can attach to to give us some level of control plane to execute a Zero Trust philosophy.”
Aditi, specifically for you, what would you say is the most important thing, and why does DNS excite you when it comes to creating a new Zero Trust approach for connections?
Aditi: Yeah, so when it comes to why DNS, I would say, like David had rightly mentioned, if most of the connections out there are using DNS, that means DNS has become the core protocol for discovery. There are very few application connections making direct IP-based connections regardless. And it makes complete sense because DNS supports massive scale. Think about global distributions, think about CDNs, the ability to load balance—we probably wouldn’t be able to do any of this if we were trying to use straight IP connections or trying to remember the IP address for our favorite website and just connect to that.
DNS has given us this capability, and in today’s world, there’s no going back. I think the biggest part about DNS is the scale that it provides. I don’t think we can go back to a world where scale is not supported, because the entire world is living on the web these days. Going back to IPs where you have to remember the IP address for your favorite website and try to connect to it—that’s not happening anymore.
Francois: Agreed. Yeah. The other interesting thing—especially when we think about IPv6—you talk about scalability, and you want to prevent bad connections from happening. If you take the status quo security approach where you say, “Okay, bad guy does something, now let’s shut him down,” with IPv6 you have enough IPs that you could spear-phish every human on the planet (if the math is done right) 47 octillion times before you get a collision. So the idea of just blocking what’s bad from the IP side of things is not very practical. That’s not really an option.
David, what have you observed when it comes to malware and direct IP connections versus DNS? What is your opinion there?
David: Well, after many years of fighting malware and helping unfortunate clients out of situations that they didn’t want to be in in the first place, and observing a pattern, it’s very clear that the more advanced a threat becomes, the more time and effort the threat authors put into leaving few breadcrumbs behind when they use DNS.
They are aware that they’re leaving breadcrumbs in a lot of places potentially—not only in the company’s passive DNS server that they have attempted to attack, but also with threat intelligence providers that will then immediately distribute it. Before you know it, it becomes part of a public threat intelligence feed, and then all of a sudden their threat is no longer able to execute.
So what they do is say, “Well, how do we just not do that?” They’ll just rent a virtual private server from a cloud provider that doesn’t have a very strong enforcement policy, and then not use DNS at all. Their malware now uses direct IP connections to reach their command and control. By not using DNS, they’re leaving a lot fewer breadcrumbs around. And because IPs are so easily recyclable with many cloud providers around the world, it actually ends up being a technique that just keeps on working.
Francois: Yeah, and evasion is part of the attack, right? You have to plan for that. Even if they do use DNS, if we can get to a world where everything is denied by default and it actually becomes practical, then it doesn’t matter that you spin up a new domain because it’s going to be denied anyway. You just don’t have proper intelligence that says, “Okay, this is verified in a Zero Trust environment; there’s enough here to say that we should allow this connection to take place.”
It really gets us to a place where DNS can be used as a root of trust and then be used as an enforcement layer to have a Zero Trust approach for every connection. Aditi, how does Microsoft, with ZTDNS, actually do this?
Aditi: Yeah, so specifically for Windows devices, Zero Trust DNS is how we took the idea of deny-by-default and tried to make it enforceable. Instead of best-effort filtering, we wanted to make sure that we have deterministic enforcement. By that, I mean we made sure that all outbound connections are blocked by default.
That was our block-by-default approach: only if a destination is explicitly allowed by policy—in this case, DNS policy—will the connection actually go through. Otherwise, because of the deny-by-default approach, all other connections are blocked. What that essentially means is that if you don’t have a valid DNS resolution, you’re not going to be able to make a connection.
Now, there are some caveats to this. Just like David mentioned, there is that less-than-1% scenario where applications make straight IP-based connections for performance reasons. We do give a credible way for trusted sources, like an IT admin, to make that decision for their enterprise. But any malware that does not have admin rights on the machine will not be able to do that. That’s basically how we, at least for Windows, have made that shift from “detect and respond” to “prevent by default.”
Francois: David, can you explain the ADAMnetworks “Don’t Talk to Strangers” approach to us?
David: Yes, that is very similar to what Aditi just explained with how Microsoft does it on Windows, but instead of it being at the endpoint itself, it now takes place at the nearest Layer 2/Layer 3 gateway. In an enterprise, it sits closest to the distribution switch, if you will, where there is Layer 2 visibility—meaning that the endpoint can be seen right down to the MAC address. That way, it can inform as to the identity of the device so that the correct policy can be applied to the endpoint.
Similar to the Microsoft Zero Trust DNS approach, any destination must first be allowed and resolvable by policy in order for that destination to be permitted. Because IP addresses could host any number of domain names and could change content over time, we also time-bound it in that case. After the period of Time-to-Live (TTL), or some percentage of extra time that’s configurable, that open hole gets closed.
There might be a schedule; there might be, for example, no reason for an end-user device to be reaching out anywhere at nighttime when the only things that should be happening are backups, updates, and so forth. That’s how we apply the “Don’t Talk to Strangers” approach at the gateway layer.
Francois: Yeah. The easiest way to think about it is just to say, look: in this ADAMnetworks environment, all connections are disallowed by default unless asked for by DNS—verified device to a verified destination, controlled by policy. An easy way to think about it is like mini-firewalls spun up for every connection. If a verified device asks for it to a verified destination, at the end of the Time-to-Live, we just collapse that connection.
Again, think of it this way: general connectivity usually has two gates next to each other. It’s a “nice-to-have” to say, “Okay, first I’m going to go through the DNS gate, and if I did go through that, fine—then it resolves to the IP and the connection takes place.” But we change it so that every single connection requires that DNS lookup. Now we actually have the ability to enforce this connection request against the security plane—the root of trust that you choose to use there.
The other thing, David, that’s really interesting here is that doing this out-of-band suddenly means that you don’t need any endpoint agent to run on any of these devices. Now you’re talking about protecting unprotectable devices: medical IoT, industrial IoT, anything. That really makes things very, very interesting.
David: Here is an IP address that I’m going to try to send a regular ping to from a computer that does not have any kind of agent, but lives behind a gateway that’s running “Don’t Talk to Strangers.” You can see that as I’m attempting to ping it, it is unable to reach that destination because, at the moment, that IP address is a “stranger.”
If I try to resolve [www.example.com](https://www.example.com), you see that it resolves to that IP address, and now I am able to ping it—no problem—for the period of the Time-to-Live. That is an example of how “Don’t Talk to Strangers” is friendly in that it converts a stranger to a non-stranger, but it’s very forgetful: after the Time-to-Live expires, it’s forgotten and becomes a stranger again. It deals with a little bit of a memory issue, but on purpose, and it happens to work well.
Aditi: For Zero Trust DNS, let me quickly walk you through how it works at a very high level on a Windows device that has Zero Trust DNS enabled. Imagine that you’re trying to reach site.example. All outbound connections are blocked by default. A resolution for site.example needs to be made and received from your trusted DNS server, which you’ve already configured as part of the ZTDNS configuration.
Only if you receive a successful resolution will your device be allowed to make outbound connections to the web server hosting site.example. Any other connection attempted would be blocked. That is a very high-level overview of what Zero Trust DNS does on your device when enabled.
Francois: David, can you dig in a little bit more on the decision tree for every connection under this Zero Trust connectivity approach? How does that actually function?
David: Well, the Protective DNS component that is part of the Microsoft Zero Trust DNS configuration process—which is also what we apply in conjunction with “Don’t Talk to Strangers”—is an important element. If you only require IP addresses to be discovered by DNS, but then you’re allowing bad domain names through, you really haven’t solved all of the problems.
Protective DNS is about saying: how do we solve this problem of a billion domain names—600 million of which are active, 10 million of which are commonly cached places, a million are well-categorized, and 15,000 are all you really need? It’s a very complex numbers game that has been broadly taken care of with Protective DNS. By having a way to identify a domain name’s tagging or categorization and creating a policy on whether it should be allowed or not, you automate that without introducing unnecessary latency.
That is really the role of Protective DNS. We can have ADAMnetworks be that Protective DNS server for the Zero Trust DNS endpoints. In effect, the two can work together by ADAMnetworks being the Protective DNS server, while the “Don’t Talk to Strangers” piece can be set up to apply only to non-Windows endpoints. That way, you have Zero Trust DNS protecting the Windows endpoint, and “Don’t Talk to Strangers” protecting everything else.
Francois: Let’s jump back to Protective DNS. What you’re referring to specifically is the ability for the ADAMnetworks solution to aggregate multiple Protective DNS resolvers. How can you guarantee that you have the best threat feed in the world? You can take the top three of your choice and combine them—vendors that wouldn’t normally talk to each other—aggregate that result, and if you’re a government agency forced to use CISA’s protected resolver, you can still do that while getting something better by aggregating Tier 1 solutions on top of that, right? That’s also quite exciting.
David: Yes, it is. If I can just add to that real quick: years ago, I remember being super excited when the concept of Protective DNS wasn’t even called that yet. There were some vendors that were really good at what they were doing, and there were other vendors that were really good at what they were doing, but the Venn diagram only had partial overlap. I wanted the Venn diagram of both of them.
That’s how DNS Harmony was born. We said, “Okay, we know Infoblox is really good at it, but we also know that there are some niche providers that inform Quad9. How can I add Quad9 with Infoblox?” We don’t think of them as competitors; we think of it as wanting both.
Francois: Yeah. And now that preemptive defense is a thing, that can become part of your threat feed as well. That definitely gets things a lot more interesting, for sure.
What really excites me is that it means you can now have protection on everything—from your Windows endpoint to your surgical laser, to the light bulb, to the fish tank thermometer—it doesn’t matter. Everything can actually now be protected, and you don’t need an endpoint agent as part of this solution.
That suddenly becomes really interesting because one of the big problems that needed to be solved in the world of Zero Trust is: what about those things that just can’t get that identity management, or can’t run that agent? What do you do with those? It’s really exciting that this actually solves that sector as well.
But that said, we have to answer the question: why should the industry care? New technology is really cool, but it only becomes valuable if it’s useful, practical, and actually changes people’s lives. Aditi, why should the industry care about this?
Aditi: I think, Francois, especially for the network and security providers out there, this brings in a mindset shift. Instead of asking, “How do we detect bad things faster?” we urge everyone to think about, “How can we prevent bad things from happening in the first place?”
I truly believe that technology problems are the easiest to solve; people problems are the hardest to solve. Getting the industry to actually think in a different direction is going to be the hardest part. We already have solutions, and you already have smart people thinking about it. Protective DNS is already out there making sure that it has the best threat intel in the world, detecting bad guys faster, and tagging malicious domains. They’re using all the information available, lots of research is happening, and great things are being done on the Protective DNS server side.
However, from the endpoint’s perspective, where we are actually starting these connections, security is treated as a nice-to-have, best-effort approach at this point, and it’s very easy to bypass. What we are bringing in through this discussion is a way—even though we have all of this intelligence sitting somewhere—to be able to enforce it so that we block all bad connections in the first place. That’s kind of where we’re trying to take the industry.
David: You know, people with my level of gray hair—maybe 30% more—would say, “No, we tried default-deny. It doesn’t work. We’ll never go back there.” They literally have PTSD from the days when they were managing Cisco IOS ACLs—that’s Cisco’s original operating system before Apple called their iPhone operating system iOS, and ACLs were their Access Control Lists.
By me using these terms, I’m literally creating PTSD responses in people who are trying to retire now! Put a disclaimer at the bottom for people who are starting to get seizures right now!
There was a time when we actually managed outbound connections with default-deny egress control, and we abandoned that because it became unwieldy and unmanageable when the priority of the C-suite was “get things to work” rather than getting things secured. But now that we have no choice but to get things working, optimized, and secured before launch, we need to revisit that.
That mindset change you’re talking about is absolutely the case. This is our appeal: try it again, because we’re now applying the right kind of technology. Egress control and default-deny in the right way that is actually practical.
Francois: Yeah, for sure. I think the thing that excites me most is the consequences that come from applying this technology in the wild. Not everything is apparent right now because the whole industry has become so used to the status quo of security, where we react faster, respond faster, and try to put out fires.
Actively living in a default-deny world gives you a defense against zero-days. You don’t have to be Patient Zero—someone else gets to be Patient Zero. Just as Aditi said, it’s all well and good for the industry to look at the corpse and do forensics on the person that was hit first, but that’s no good if it was you, your systems, or the people you care about.
And what if threats are not detectable? Well, if that threat is never allowed to connect, then it doesn’t matter that it has detection evasion, because you’ve neutralized it without ever needing to detect it. Suddenly that’s a completely different mind shift. There are so many exciting consequences here that we’ve just begun to explore regarding how much it changes your security posture when actively implemented. You move to a truly proactive posture.
What about consumers? We spoke about the industry, but why should enterprises and consumers care? I’m going to throw it to you again, Aditi. What’s the most important thing to you?
Aditi: I think the reason enterprises and consumers should start educating themselves about this is because the internet today has become a universal threat ecosystem. We want to take it back to being a tool rather than a threat surface. That’s literally where Zero Trust comes in.
Adopting Zero Trust is a journey. It is not going to happen in a day; it’s not a switch you can flip. It requires planning, testing, and careful rollout to make sure your business continues while you’re trying to make it more secure. In order to reach that North Star, education is the first step. Then, taking account of and auditing your existing deployments. Once you actually know what exists, you can start planning toward a brighter Zero Trust future.
David: You’re absolutely right, Aditi. That mindset shift takes a little bit of time to be realized, but it only takes the experience of rolling it out to say, “Wait a minute, this is better.” Especially when you take a smart rollout approach where nothing is broken in the process: you simply utilize tools available to say, “These resources need direct IP connections, so we provision them. This service is a mission-critical part of this network, so that becomes allowed.” By the time you roll it out, the end users don’t even experience a hiccup.
That kind of experience—followed up by observing an attack that has been blocked where the attacker never even knew the payload failed to launch, and your security team is looking at the event log of what could have gone wrong but was neutralized before it could execute—there is no better feeling than that for a defender.
Francois: Absolutely. In a Zero Trust world, if you can do it in a way that is transparent to the end users, they live in a Zero Trust connected environment and get to take control—especially with the ability to have multiple policies designed to fit individual devices.
Suddenly you have a non-uniform attack surface. You could say, “I want my version of the internet to be unique from all other devices on this organization’s network. I choose what the internet is for me.” I get to command the internet. The defenders protecting the end user get to command what the internet is for them and for the organization.
That’s huge. Because what you’re saying, Aditi, is that in a Zero Trust environment: click anywhere! You don’t have to worry about phishing because it’s not a verified connection. You don’t have to catch it and then block it—it’s already blocked; it’s already shut down. As an internet user myself, protecting people I care about from harm is a massive win. It’s absolutely something people need to look at seriously and in depth.
Okay, that’s already a lot and enough for our first session on this topic. In conclusion, Aditi, what would you want to say to the world out there to end the session?
Aditi: For me, the most exciting part—like I mentioned earlier—is that while the internet has become a universal threat ecosystem, we are getting control back. That is what’s so exciting.
Francois: Absolutely. David, in conclusion, what’s the most exciting part for you?
David: I find myself agreeing with you again, Aditi. The way we will take it back is to get rid of the porosity of the internet. When we do that successfully, we will effectively make it too expensive for the attacker. The attacker at that point either moves on to someone else or gives up altogether.
Francois: Yeah. And for me, the most exciting part is that I get to command what the internet is for me. I don’t have to change it for anyone else, but for me and the people I’m protecting, I get to tell the internet what it is. With Zero Trust connectivity, ZTDNS, and “Don’t Talk to Strangers,” we have the ability to change the world one connection at a time. To me, that’s super exciting.
Well, that’s it. That’s the first session on ZTDNS, “Don’t Talk to Strangers,” and Zero Trust connectivity. Check out the links for additional white papers and information, and we’ll see you in the next one. Bye-bye!
Links
https://www.gartner.com/en/articles/preemptive-cybersecurity-solutions https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/zero-trust-dns/ https://adamnet.works/how-it-works/
