Introduction

Strangely, identity and name resolution have become interesting to me as they essentially underpin the infrastructure of the modern Internet. In some ways, the industry has given up on the security of DNS, with its ability to be susceptible to man-in-the-middle attacks, allowing attackers to hijack communications and possibly turn them into an attack vector.

This has often meant that bringing cloud management and security tools into an on-premises network has left me fighting with the customer’s network administrators to get traffic allowed listed and, in some cases, having packet inspection turned off. With DNS, there is mistrust as the protocol is old and rather insecure; this has forced some network administrators to allow IPs but not DNS names. This approach to allow listing can work, but it often falls apart when the service provider, i.e., needs to change the IP of a service.

But why such mistrust? At its core, DNS is an unencrypted communication system, a huge problem on the modern Internet. Financial attacks related to hijacking entire DNS domains have become a reality, making customers more reliant on network and device security products to prevent bad actors from attacking users and their devices.

Introducing DNSSEC

DNSSEC uses signatures to prove the validity of the data to the client requesting a record from a DNSSEC-enabled server. It was meant to protect against DNS cache poisoning and DNS spoofing attacks making DNS much more trustworthy. Many see this as sufficient because the authenticity of the response is proven for domains that are DNSSEC enabled.

Part of configuring DNSSec is to use DNS servers that support DNSSec; this means that you can use public resolvers like:

Provider Primary DNS Secondary DNS
Google 8.8.8.8 8.8.4.4
Control D 76.76.2.0 76.76.10.0
Quad9 9.9.9.9 149.112.112.112
OpenDNS Home 208.67.222.222 208.67.220.220
Cloudflare 1.1.1.1 1.0.0.1
AdGuard DNS 94.140.14.14 94.140.15.15
CleanBrowsing 185.228.168.9 185.228.169.9
Alternate DNS 76.76.19.19 76.223.122.150

More importantly, you must also enable DNSSEC for your domain records to protect them. This is usually a simple configuration process for an external domain provider. Still, you can also reconfigure your DNS if you are hosting your external domain on your own DNS servers. About 92% of top-level domains support DNSSEC; second-level domains such as .com see only 4.3% adoption and 5.3% of .net.

Despite being better, there are many barriers to the adoption of DNSSEC. Depending on the DNS implementation, this process can be very complex, but major domain registrars have simplified it if you use their DNS hosting services. Adoption is another major issue as many organizations have not enabled DNSSEC for their domains, and to make things slightly more complicated, not every domain registrar will support DNSSEC.

The added latency for DNSSEC communications might not be ideal for some use cases. Still, the validation process takes longer, making the solution less desirable, especially with high query volumes. Also, sometimes, your DNS infrastructure may not support DNSSEC, which could stop the implementation or require changes to your current DNS infrastructure.

Finally, DNSSEC, while better than traditional DNS, doesn’t fully protect communications from denial of service attacks, privacy, and overall security. It is an improvement, and some say it is good enough to get signed DNS responses, but there still was a need to secure DNS further.

DNS Over HTTPS and DNS Over TLS

DoH and DOT are more extensive protocols as the DNS traffic is encapsulated in an SSL or TLS connection to add privacy and a valid secure connection between the client and the DNS server. The enhanced security in this scenario has led to more security at the cost of management; network devices that may inspect/filter DNS responses cannot read the contents of DoH/DOT responses, making some approaches to auditing and managing network traffic obsolete.

Generally DoH can be summarized into the key elements:

  1. Privacy Protection:
    • User Privacy: DoH helps protect user privacy by encrypting DNS queries and responses, preventing eavesdroppers from seeing which websites users visit.
    • ISP Snooping Prevention: Prevents Internet Service Providers (ISPs) from snooping on DNS queries, which can be used to track user behavior and serve targeted ads.
  2. Security Enhancement:
    • Mitigation of DNS Spoofing: Using HTTPS, DoH reduces the risk of DNS spoofing attacks (man-in-the-middle attacks) that can redirect users to malicious sites.
    • Integrity Verification: Ensures that the DNS responses are not tampered with during transit.
  3. Bypassing DNS Censorship:
    • Circumventing Government Censorship: Users can bypass DNS-based censorship imposed by governments or organizations by encrypting DNS traffic.
    • Access to Restricted Content: This feature helps users access content that may be restricted or filtered based on DNS queries.
  4. Enhanced Performance:
    • Reduced Latency: Integration with Content Delivery Networks (CDNs) can reduce latency and result in faster DNS resolutions.
    • Caching: Improved caching mechanisms with HTTPS can lead to better DNS resolution performance.
  5. Unified Protocol Usage:
    • Streamlined Traffic: Consolidates DNS traffic with regular HTTPS traffic, making identifying and blocking DNS queries harder.
    • Simplified Configuration: Simplifies network configuration using a single protocol for web and DNS traffic.
  6. Developer and Enterprise Use:
    • Application-Level DNS Control: Applications can directly perform DNS resolution without relying on the operating system’s DNS resolver.
    • Enterprise Security Policies: Enterprises can enforce security policies using trusted DoH resolvers and monitor encrypted DNS traffic through audit logging.

There are many considerations when delivering this infrastructure. Delivering certificates to all devices or applications needing DOH/DOT DNS services is a start. Still, you can’t assume all devices support it, though some applications, such as a browser, might. Users may bypass your traditional DNS with DOH by configuring it in the browser but not the operating system, causing DNS management headaches.

Like other DNS architectures, you end up placing a great deal of trust in the DNS server attached to the client. When choosing an architecture, the DNS server will likely be something you manage rather than using a public DNS. Because this infrastructure relies on HTTPS, addressing protocol issues on DNS servers and client devices will be important.

Though this approach has led to many improvements, it has not gone far enough to meet the demands of zero trust, which has become the driver of what I would call a next-generation security posture. Next, we explore the latest and greatest, which is ZTDNS.

Introducing ZTDNS: The Need to Go Further

The enhancements to DNS allowed for more privacy and security, but they lacked zero-trust properties. Microsoft recently started taking a crack at locking down DNS with Zero Trust DNS or ZTDNS. I don’t expect to see ZTDNS being used extensively but what I do see is an alternative to an air-gapped network that can extend to endpoints working from home or public networks.

ZTDNS offers low-level network control that works with the Windows Filtering Platform to block outgoing network traffic by default. Allow lists are built using domain name-based lists stored on a protective DNS server. Optionally, this DNS server can require client certificates to be presented when connecting to it to provide both server and client validation of endpoints when communicating DNS over HTTPS. Once the DNS response is sent to the client for a query, the Windows Filtering Platform will allow connectivity to the IP associated with the DNS entry.

ZTDNS is unique because the block by default posture makes devices behave much like they are on a hardened network, but the scope of the implementation could include roaming users. The goal is to only communicate with what you trust at the network level while being able to grapple with the concept that your internal network on its own should not be considered a zone of trust.

Examples of policy can be seen driving this technology. Inside of the Federal Zero Trust strategy with the United States the following directive is make for guidance with DNS.

CISA Pillar #3 for implementation in 2024.

3. Networks: Agencies encrypt all DNS requests and HTTP traffic within their environment and begin executing a plan to break down their perimeters into isolated environments.

M-22-09 Federal Zero Trust Strategy (whitehouse.gov)

NIST also refers to DNS in NIST Special Publication 800-207, but it has more to do with the use of PEPs to control data communications before applications make connections to resources. NIST talks more about theory than specific products and configurations.

Zero Trust Architecture (nist.gov)

Much of this document explains why something such as ZTDNS would need to exist: A Policy Enforcement Point (PEP) for name resolution would drive the filtering of outbound network connections. ZTDNS offers a hardened DNS that provides name resolution based on policies. Those policies are then enforced on the Windows device at the kernel level using a filter driver.

ZTDNS Architecture

This scenario involves a device on a work-from-home network trying to connect to www.contoso.com. With most DNS configurations, this happens automatically without much security. This scenario is done with the least privilege, so let’s go through some key components.

  1. A Windows 11 device has been configured using MDM policy; this sets several configuration items such as:
    1. Allowed Subnets (not encouraged)
    2. DNS Server List
    3. Client Certificate
    4. Trusted Root Certificates
  2. When the device goes home with the user and communication is established with Wi-Fi, only DHCP and NDP communication is allowed.
  3. The device must then communicate with a Protective DNS Server configured using Intune.
    • DOH/DOT DNS server
      • Root Certificate
      • SSL Certificate
  4. This server can reject clients without a valid certificate and be configured to resolve only specific domain names. This is where the DNS resolution of www.contoso.com is performed and sent back to the client over an SSL/TLS connection.
  5. The site is then added to the client’s allow list; at the Windows filter driver level, outbound traffic is allowed to the IP before name resolution happens with the application.
  6. The application receives the DNS information and then connects to www.contoso.com as usual.

If the user tries to connect to https://www.google.com, the client checks the Protective DNS Server for the IP address and does not get a resolution because the DNS domain is not in the allow list. Because this was unsuccessful, the Windows 11 device will not open any destination IP to enable traffic to google.com. If this were successful, the Windows Filter Driver on the client device would allow connectivity to the external IP address before notifying the calling application of the DNS result, making this process transparent to the application.

Although the Windows Filter Driver in this architecture might not seem significant, it is a little secret sauce that Windows uses to create deep-level system behavior changes. In the case of ZTDNS, it is networking, but the Windows Filter Drivers are used for user profile data redirection, App-V, and even antivirus software.

The Protective DNS server can also learn about your devices regardless of location; by using client certificates, it can trust client devices to be part of the name resolution service. By default, if a device is not learned or on an exception list, the DNS resolution of that entity will not occur. Using this method, you can build a policy-based DNS infrastructure that eliminates many attack vectors and a secure network with devices that mutually trust the protective DNS server.

To further demonstrate how security is enhanced, the machine could be using unsanctioned remote help software or, worse yet, being under control by malicious software. Phishing may also be part of the scenario to get software onto devices by tricking users into clicking links to malicious code. Unless the DNS domains are on the allow list, these methods are rendered useless by not allowing an outbound connection by default.

A device such as a printer on the same subnet is not visible to the Windows 11 device because name resolution with the DNS server and outgoing network connectivity will fail. I hope this emphasizes the zero-trust aspect of this DNS implementation.

With this DNS scheme, it is essential to note that this DNS architecture will not fall back to a local or remote DNS server. This service requires you to configure and manage DNS servers specified via Intune policy and ensure that protective DNS servers are accessible from the networks where your devices will be located.

A diagram of a computer network Description automatically generated with medium confidence

ZTDNS Challenges

Like any highly secure technology, challenges may limit the use cases for ZTDNS; at this point early in the product’s lifespan, expect limitations with the configuration, deployment, and management of DTDNS. Organizations that have a clear use case may opt for this design. Still, especially with Windows endpoints, there is much to consider when developing allow lists for all cloud services and applications. Even many websites have content delivered from multiple domains to build the webpage, which can be a burden to analyze and configure.

In addition to the basic connectivity requirements to operate Windows and a web browser, there are many other considerations. Below is a list of potential friction points you should consider.

1. Printing: ZTDNS, by blocking multicast DNS (mDNS), may disrupt the automatic discovery of printers on the network. However, services like Universal Print provide a secure means for administrators to configure printers through trusted device management. This allows printer endpoints to be resolved through ZTDNS, ensuring secure printer setup without relying on mDNS.

2. File Shares: ZTDNS restricts the discovery of network file shares, potentially affecting user access to shared files and folders. However, if the Protective DNS servers utilized by ZTDNS also serve as local network DNS servers, access to file shares within the local network can still be facilitated. This enables users to access and utilize local network resources seamlessly, even with ZTDNS active.

3. Windows Update: While Windows Update functionality remains intact with ZTDNS activated, there may be an increase in traffic to Windows Update services. This is because ZTDNS blocks the local network peer-to-peer traffic that Windows typically employs for sharing already-downloaded updates between devices on the same network. Enterprises can mitigate this by implementing Microsoft Connected Cache (MCC) or Windows Server Update Services (WSUS) to reduce the volume of Windows Update traffic.

4. Teleconferencing Apps: ZTDNS may interfere with teleconferencing applications that utilize WebRTC for video calls. Since WebRTC relies on IP addresses discovered through STUN and TURN protocols rather than DNS queries, ZTDNS may inadvertently block these connections. To address this, administrators can configure IP exceptions in ZTDNS for the specific IP address subnets required by teleconferencing applications, ensuring uninterrupted functionality.

5. Media Streaming: While DNS-based media streaming typically remains unaffected by ZTDNS, other media streaming scenarios relying on non-DNS endpoint discovery may be impacted. This includes local network media discovery and streaming, such as sharing music libraries or streaming video from a home media server, which often utilize protocols like Universal Plug and Play (UPnP) that are incompatible with ZTDNS.

6. Casting to Wireless Displays: ZTDNS may prevent browsers and other applications from discovering castable wireless displays. This limitation arises because ZTDNS blocks certain discovery mechanisms that these applications rely on. As a workaround, users may opt to use physical connections to the intended display device instead of relying on wireless casting.

7. Captive Portals: ZTDNS disrupts the traditional method of redirecting clients to captive portal pages by intercepting plain-text DNS queries. This means that standard captive portals relying on this method will not function properly when ZTDNS is active. While some networks may support structured advertisement of captive portal properties, this approach is not compatible with ZTDNS at present, rendering navigation of captive portals unsupported.

8. Browsers Using Encrypted DNS: Browsers equipped with their own encrypted DNS clients may encounter issues when attempting to resolve domain names with ZTDNS active. This is because ZTDNS may either prevent the browser from resolving names altogether or hinder traffic to resolved IP addresses. To mitigate this, administrators can disable the use of encrypted DNS within the browser settings, ensuring compatibility with ZTDNS and other Windows mechanisms.

9. Apps with Hard-Coded IPs: Administrators may discover that certain applications within their environment rely on hard-coded IP addresses or non-DNS name resolution mechanisms. To address this, a controlled rollout of ZTDNS, initially in audit mode, can help identify such applications before enforcing outbound blocks. It’s important to note that even in audit mode, ZTDNS may disrupt experiences reliant on non-DNS name protocols, such as mDNS, LLMNR, and NetBIOS name resolution.

Bypassing ZTDNS

Additionally, there are ways to bypass and interfere with DTDNS. Most of it would be edge use cases, but being aware of these possibilities is an essential part of the design process for your DTDNS environment.

1. VPN or SASE/SSE Tunnels: Technologies like VPNs and SASE/SSE solutions can bypass ZTDNS enforcement. When ZTDNS is active, these tunneling technologies will still function if the gateway’s domain name is allowed or ZTDNS manually permits the IP address. However, traffic sent over the tunnel will appear associated with the domain name or exception name for the gateway’s IP address rather than the initially resolved domain name by the app sending the traffic. Administrators should conduct domain name auditing at the tunnel’s exit node to maintain similar lockdown-by-domain-name functionality.

2. Hyper-V VMs, including WSL: Virtualization technologies like Hyper-V, including Windows Subsystem for Linux (WSL), implement their own networking stack, bypassing the host’s TCP/IP stack and, therefore, bypassing ZTDNS enforcement. WSL, part of the Windows Insider ZTDNS preview, is a notable example of this bypass behavior.

3. Stack Bypass Technologies: Technologies like XDP or DPDK that bypass the Windows 11 host networking stack will also bypass ZTDNS and any other Windows feature that enforces traffic through the Windows Filtering Platform.

4. Local Administrators: Enterprise administrators should consider the implications of granting administrative privileges to employees on Windows devices. Local administrators can easily deactivate ZTDNS enforcement, add exceptions for malicious IP addresses, or install and run software with administrative privileges, potentially circumventing ZTDNS. Therefore, deploying ZTDNS to Windows 11 machines in an enterprise environment with regular human users having administrator privileges is not supported. The recommended approach is to manage devices fully through Mobile Device Management (MDM), with local controls reserved for debugging purposes only, aligning with Zero Trust principles of granting only the necessary access or permissions.

ZTDNS Use Cases

Despite many pain points, there will be scenarios where this endpoint lockdown makes sense. For me, the mysterious world of the KIOSK or task-based device makes the most sense. These devices can be digital signage, shared devices for frontline staff, or point-of-sale devices. The constant I see between these different device personas is the specialization of the device purpose to the degree that much of the device functionality is restricted by default and could greatly benefit from being put in a zero-trust architecture.

I am also curious whether Azure Virtual Desktop or Windows 365 would be good candidates. Using these endpoints with ZTDNS would enable strict communication rules at the network level to reduce the network surface area exposed to those endpoints. But for now, technology is in private preview, and the first versions may be complex and painful to implement, but I don’t see this approach to network security disappearing, even if it is more of a niche use case.