Microsoft plans to lock down Windows DNS like never before. Here’s how.

Translating human-readable domain names into numerical IP addresses has long been fraught with gaping security risks. After all, lookups are rarely end-to-end encrypted. The servers providing domain name lookups provide translations for virtually any IP address—even when they’re known to be malicious. And many end-user devices can easily be configured to stop using authorized lookup servers and instead use malicious ones.

Microsoft on Friday provided a peek at a comprehensive framework that aims to sort out the Domain Name System (DNS) mess so that it’s better locked down inside Windows networks. It’s called ZTDNS (zero trust DNS). Its two main features are (1) encrypted and cryptographically authenticated connections between end-user clients and DNS servers and (2) the ability for administrators to tightly restrict the domains these servers will resolve.

Clearing the minefield

One of the reasons DNS has been such a security minefield is that these two features can be mutually exclusive. Adding cryptographic authentication and encryption to DNS often obscures the visibility admins need to prevent user devices from connecting to malicious domains or detect anomalous behavior inside a network. As a result, DNS traffic is either sent in clear text or it's encrypted in a way that allows admins to decrypt it in transit through what is essentially an adversary-in-the-middle attack.

Admins are left to choose between equally unappealing options: (1) route DNS traffic in clear text with no means for the server and client device to authenticate each other so malicious domains can be blocked and network monitoring is possible, or (2) encrypt and authenticate DNS traffic and do away with the domain control and network visibility.

ZTDNS aims to solve this decades-old problem by integrating the Windows DNS engine with the Windows Filtering Platform—the core component of the Windows Firewall—directly into client devices.

Jake Williams, VP of research and development at consultancy Hunter Strategies, said the union of these previously disparate engines would allow updates to be made to the Windows firewall on a per-domain name basis. The result, he said, is a mechanism that allows organizations to, in essence, tell clients “only use our DNS server, that uses TLS, and will only resolve certain domains.” Microsoft calls this DNS server or servers the “protective DNS server.”

By default, the firewall will deny resolutions to all domains except those enumerated in allow lists. A separate allow list will contain IP address subnets that clients need to run authorized software. Key to making this work at scale inside an organization with rapidly changing needs. Networking security expert Royce Williams (no relation to Jake Williams) called this a “sort of a bidirectional API for the firewall layer, so you can both trigger firewall actions (by input *to* the firewall), and trigger external actions based on firewall state (output *from* the firewall). So instead of having to reinvent the firewall wheel if you are an AV vendor or whatever, you just hook into WFP.”

How it works

Microsoft provided a conceptual illustration showing how ZTDNS will fit into its mobile device management platform—which helps admins secure and control remote devices authorized to connect to a network—and interface with devices connected from home or other remote locations.

ZTDNS blocks outbound connections from the client device to all IPv4 or IPv6 IP addresses except for those to protective DNS servers, DHCP, DHCPv6, and NDP servers as needed for network discovery.

Microsoft continued:

Going forward, DNS responses from one of the Protective DNS servers that contain IP address resolutions will trigger outbound allow exceptions for those IP addresses. This ensures that applications and services that use the system DNS configuration will be allowed to connect to the resolved IP addresses. This is because the destination IP address will be approved and unblocked before the domain name resolutions are returned to the caller.

 

IP addresses allowed

Microsoft

 

When applications and services try to send IPv4 or IPv6 traffic to an IP address that was not learned through ZTDNS (and is not on the manual exceptions list), the traffic will be blocked. This is not because ZTDNS tried to identify malicious or forbidden traffic to block, but because the traffic was not proven to be allowed. This makes ZTDNS a useful tool in the Zero Trust toolbelt: it assumes traffic is forbidden by default. This will allow administrators to define domain-name-based lockdown using policy-aware Protective DNS servers. Optionally, client certs can be used to provide policy-affecting client identities to the server rather than relying on client IP addresses, which are both not secure signals and not reliably stable for work-from-anywhere devices.

 

Domain-name-based lockdown

 

By using ZTDNS to augment their Zero Trust deployments, administrators can achieve name labeling of all outbound IPv4 and IPv6 traffic without relying on intercepting plain-text DNS traffic, engaging in an arms race to identify and block encrypted DNS traffic from apps or malware, inspecting the soon-to-be encrypted SNI, or relying on vendor-specific networking protocols. Instead, administrators can block all traffic whose associated domain name or named exception cannot be identified. This renders the use of hard-coded IP addresses or unapproved encrypted DNS servers irrelevant without having to introduce TLS termination and miss out on the security benefits of end-to-end encryption.

 

Comparison system with and without ZTDNS

Microsoft

 

For DNS servers to be used as Protective DNS servers for ZTDNS lockdown, the minimum requirement is to support either DNS over HTTPS (DoH) or DNS over TLS (DoT), as ZTDNS will prevent the use of plain-text DNS by Windows. Optionally, use of mTLS on the encrypted DNS connections will allow Protective DNS to apply per-client resolution policies. In all cases, ZTDNS does not introduce any novel network protocols, which makes it a promising interoperable approach to domain-name-based lockdown.

Ryan Hurst, CEO of Peculiar Ventures, said that the mass adoption of encrypted connections inside networks has created difficulties in some large organizations because so many of the security tools admins use rely on their ability to inspect and monitor plain-text traffic. In an interview, he wrote:

One of the theses of this Zero Trust DNS solution appears to be that by turning DNS into what we used to call a Policy Enforcement Point for the network enterprises get some of that visibility back. While they do not get cleartext traffic, they do get to reliably control and audit what domain names you resolve. When you combine that with egress network filtering, it has the potential to create a closed loop where an enterprise can have some confidence about where traffic is going and when. While I would not want my ISP to do any of this, I think it's quite reasonable for an enterprise to do so; it's their machine, their data, and their traffic. It also has the potential to be used as a way to make lateral movement in a network, when a compromise takes place, harder and maybe, in some cases, even make exfiltration harder.

All three security experts interviewed for this post cautioned that ZTDNS introduces a novel paradigm that could disrupt crucial network operations unless admins make significant changes to their current designs.

“It'll definitely take some vigorous testing—and a culture shift—for orgs to build confidence in it,” Royce Williams wrote. “There will also probably need to be a pre-populated allow list, and a specific team would need to be identified to handle escalations if there's unexpected impact. ZTDNS success will likely depend strongly both on orgs understanding their existing DNS flows, and on having clear ownership of the human process of keeping it healthy.”

“To gain the most security value from ZTDNS, system admins will need to enumerate the expected domains and/or IP ranges they expect their clients to connect to,” Jake Williams wrote. “Failure to do so will result in self-inflicted denial of service.”

Microsoft published a separate post detailing some of the processes that will be complicated by ZTDNS and others that will bypass it. ZTDNS is entering private preview. Microsoft didn’t say when insiders might be able to review it or when it might become generally available.