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.”