In the modern world, useful network destinations are far more likely to be defined by long-lived domain names than long-lived IP addresses. However, enforcement of domain name boundaries (such as blocking traffic associated with a forbidden domain name) has always been problematic since it requires breaking encryption or relying on unreliable plain-text signals such as DNS over port 53 inspection or SNI inspection.
To support Zero Trust deployments trying to lock down devices to only access approved network destinations, we are announcing the development of Zero Trust DNS (ZTDNS) in a future version of Windows. ZTDNS was designed to be interoperable by using network protocols from open standards to satisfy Zero Trust requirements such as those found in OMB M-22-09 and NIST SP 800-207. ZTDNS will be helpful to any administrator trying to use domain names as a strong identifier of network traffic.
ZTDNS integrates the Windows DNS client and the Windows Filtering Platform (WFP) to enable this domain-name-based lockdown. First, Windows is provisioned with a set of DoH or DoT capable Protective DNS servers; these are expected to only resolve allowed domain names. This provisioning may also contain a list of IP address subnets that should always be allowed (for endpoints without domain names), expected Protective DNS server certificate identities to properly validate the connection is to the expected server, or certificates to be used for client authentication.
Next, Windows will block all outbound IPv4 and IPv6 traffic except for the connections to the Protective DNS servers as well as the DHCP, DHCPv6, and NDP traffic needed to discover network connectivity information. Note that many options from these protocols will be ignored, such as RDNSS, as only the configured Protective DNS servers will be used.
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.
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.
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.
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.
ZTDNS is entering private preview, meaning it is not yet publicly available for testing. There will be another announcement once the ZTDNS client is available to Insiders. For now, there is additional information about considerations for deploying ZTDNS in a real-world environment in this blog post.
Update, May 6th, 2024: come talk to Aditi Patange at the Microsoft RSAC booth about ZTDNS! (week of May 6th only)
Update, November 19th, 2024: Private Preview of ZTDNS is opening up for Windows 11 enterprise customers! If you are an enterprise interesting in testing ZTDNS in your environment, please sign up for Private Preview at aka.ms/ztdnsintake.
Microsoft
