This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

This document goes over what considerations administrators should keep in mind when evaluating how ZTDNS fits into their Zero Trust deployment model. For more information about what ZTDNS is, see this feature announcement.

Zero Trust DNS (ZTDNS) is a powerful Windows feature that enables an administrator to lock down Windows outbound IP-based traffic to endpoints approved by a Protective DNS service. However, there is no such thing as a Zero Trust silver bullet or “Zero Trust on” button.

This post will help administrators understand what to consider when deploying ZTDNS:

• What things ZTDNS will complicate (including alternative solutions to solving those same scenarios without violating Zero Trust principles)
• What will bypass ZTDNS (defining what scenarios are out of scope for ZTDNS today)

What things ZTDNS will complicate

ZTDNS, as a Zero Trust architecture enabling feature, breaks insecure networking features in ways that may not be immediately obvious. By blocking all outbound network traffic that cannot be associated with a domain name, there are many networking protocols that simply cannot function, including (but certainly not limited to) mDNS, LLMNR, NetBIOS Name Resolution, UPnP, and WebRTC.

Some of the uses cases for these protocols can be unblocked by defining narrow IP subnet exceptions, such as allowing the well-defined IP ranges required for a vendor’s software. Others cannot know their destination IP addresses in advance and will never work unless ZTDNS is deactivated or greatly crippled with broad IP subnet exceptions.

Even when creating IP address exceptions for ZTDNS, there are two major considerations to keep in mind:

• IP address exceptions should be used only when strictly necessary to prevent unmanageably long lists of exceptions, and
• Only IP addresses from the globally-unique ranges should be permitted to prevent Windows from being vulnerable to attacks from other hosts using same addresses on different networks

Note: the latter can be addressed by deploying IPv6 and creating manual IP addresses exceptions for IPv6 ULA and GUA addresses, where each address type is appropriate (note that extra care must be taken with ULA address allocation to not use predictable ranges).

This page will go over several common real-world scenarios ZTDNS will impact and, if possible, how administrators can address the original need without IP address exceptions.

Printing

Using a secure printer management service such as Microsoft’s Universal Print enables enterprise administrators to configure printers securely through trusted device management. Printer endpoints are then resolved through ZTDNS instead of being discovered using mDNS, which ZTDNS would block. More information about the endpoints Universal Print uses can be found on this page.

File shares

Trying to discover file shares on the network, such as using the Network section of Windows Explorer, will be blocked by ZTDNS. However, if the Protective DNS servers ZTDNS uses are also local network DNS servers, then file shares on the local network can be discovered and used just like any other approved domain name.

Additionally, using file hosting that can be reached at DNS-discovered endpoints, such as SharePoint, OneDrive for Business, or Azure Files, will ensure no ZTDNS workarounds are needed. This also ensures that the network connection Windows 11 uses to discover and connect to the file share is not a factor in the connection’s trust in line with Zero Trust principles.

Windows Update

Windows Update will continue to function when ZTDNS is activated (so long as its required domain names are resolved by the ZTDNS-configured Protective DNS service). However, enterprises may notice a sudden increase in traffic to Windows Update services because ZTDNS will block the local network peer-to-peer traffic Windows uses to share already-downloaded updates between devices on the same network.

Enterprises should consider using MCC (in preview for enterprises) or WSUS to reduce Windows Update traffic volume when ZTDNS prevents the peer-to-peer sharing of Windows updates.

Teleconferencing apps

Programs such as Teams, Webex, Zoom, Discord, Slack, and others use protocols such as WebRTC to stream their video calls. WebRTC in turn uses IP addresses discovered through STUN and TURN. This means that ZTDNS will end up blocking WebRTC because the IP addresses were not discovered through DNS queries.

Most vendors will disclose the IP address subnets they require for functionality to inform customers about needed firewall exceptions (such as these for Microsoft Office products). Such vendor-required IP ranges should be configured as IP exceptions in ZTDNS when resolving the required domain names is not sufficient.

Media streaming

Some forms of media streaming, such as streaming from online services through a browser, will usually work when ZTDNS is active because it will use domain names to look up the destination. Other media streaming scenarios that use non-DNS endpoint discovery will end up being blocked by ZTDNS, especially local network media discovery and streaming such as sharing music libraries or streaming video from a home media server. Universal Plug and Play (UPnP) is one of many standards used for this that will not work when ZTDNS is active.

Casting to wireless displays

Browsers and other apps may wish to discover castable wireless displays, but this will not work when ZTDNS is active. Consider using physical connections to the intended display instead.

Captive portals

Most captive portals today continue to rely on plain-text DNS query interception to redirect clients to a captive portal page. When ZTDNS is active, this will never work because Windows 11 will never emit plain-text DNS traffic. While there is a standard that allows networks to advertise their captive portal properties in a structured manner (not supported in Windows), this is not compatible with the ZTDNS approach today because the network would not allow the ZTDNS client to issue a query for the captive portal URI.

In the ZTDNS private preview, navigating captive portals is an unsupported scenario.

Browsers using their own DNS clients

Most browsers can use their own encrypted DNS clients instead of using the operating system’s DNS APIs. When a browser attempts to do this on Windows 11 when ZTDNS is active, it will either fail to resolve any names, or fail to send traffic to any resolved IP addresses (depending on whether ZTDNS permits outbound traffic to the encrypted DNS server in the first place).

Customers should use the management policy provided by their browser vendor to disable the use of encrypted DNS within the browser itself, such as this Edge policy. This is generally good practice on managed devices anyway because other Windows mechanisms also expect apps to use the system DNS resolver, such as the NRPT.

Apps with hard-coded or non-DNS-discovered IP addresses

It is likely that administrators will find one or more applications in their production environment relying on hard-coded IP addresses or non-DNS name resolution mechanisms. Administrators should do a controlled roll out of ZTDNS by first enabling audit mode; this will allow discovery of apps that would break if ZTDNS were enforcing outbound blocks in the logs without actually breaking employee productivity.

Note: even when enforcement is off, ZTDNS will still disrupt any experience that directly relies on use of non-DNS name protocols by the Windows DNS client, specifically mDNS, LLMNR, and NetBIOS name resolution. This is because when ZTDNS audit mode is on, all name queries need to be sent to the Protective DNS service to test if it would have permitted the name. Use of DNS or any other name resolution protocol by other apps, such as browsers using DNS over HTTPS, will not be blocked in audit mode.

What can bypass ZTDNS

While there are features and functionality that ZTDNS will break, there is also networking functionality which can bypass ZTDNS enforcement, either because ZTDNS is still in preview and being worked on, or because of the inherent nature of the other feature.

VPN or SASE/SSE tunnels

Any form of tunneling technology, such as VPNs and SASE/SSE solutions, will work when ZTDNS is active so long as the gateway in question is looked up by allowed domain name or the IP address is manually permitted by ZTDNS. However, once that occurs, all traffic sent over the tunnel will appear to be associated with the domain name or the exception name for the gateway’s IP address, not the domain name the app sending traffic resolved for any given traffic flow through the tunnel.

Administrators should be aware of this when they deploy ZTDNS and network tunnels at the same time and ensure they conduct ZTDNS-like domain name auditing at the tunnel’s exit node in order to maintain similar lockdown-by-domain-name functionality.

Hyper-V VMs, including WSL

Any virtualization that implements its own networking stack, and therefore bypassing the Windows Filtering Platform functionality of the host TCP/IP stack, will bypass ZTDNS enforcement. Windows Subsystem for Linux (WSL) is a high-profile example of an enterprise experience that will bypass ZTDNS enforcement in the Windows Insider ZTDNS preview.

Stack bypass technologies

Any other technology that bypasses the Windows 11 host networking stack, such as XDP or DPDK, will bypass ZTDNS and any other Windows feature that enforces traffic through Windows Filtering Platform.

Local administrators

Enterprise administrators should consider whether their employees need to have administrative privilege on their Windows devices. Any administrator can deactivate ZTDNS enforcement as easily as activate it, add ZTDNS exceptions for malicious IP addresses, or even install and run software with administrative privileges which may (unbeknownst to the human user) do these things. Therefore, deploying ZTDNS to Windows 11 machines in an enterprise environment which have regular human users with administrator privileges is unsupported. The intention is for the device to be fully managed through MDM, with local controls present for debugging purposes only, in line with Zero Trust principles (grant only the absolutely necessary access or permissions).