Zero trust at Microsoft: Windows receives zero-trust DNS client

Contents

The use of hyperscalers and their public cloud services in particular means that IP-based sets of rules only make limited sense. At the same time, DNS resolvers are distributed throughout the system and in applications and often communicate unencrypted. With Zero Trust DNS (ZTDNS), Microsoft now wants to prevent any communication without DNS, with a few exceptions, and create dynamic approvals according to the response. This should make breaking the encryption and SNI inspection unnecessary.

Background

With ZTDNS, Microsoft combines the Windows System DNS client with the Windows Filtering Platform (WFP) to implement DNS-based rules. For this purpose, the client receives a list of special DNS-over-HTTPS or DNS-over-TLS protected DNS servers, which should only resolve permitted domain names, as well as lists of server certificates to validate them. According to Microsoft, administrators can also provide the client with an IP whitelist for destinations without name resolution during provisioning. Optionally, the client can also receive a client authentication certificate for authentication against the DNS server.

In the next step, Windows blocks all outgoing IPv4 and IPv6 traffic, except for DHCPv4, DHCPv6, NDP traffic for network information and protected DNS traffic. However, the client only uses the protected DNS servers and ignores corresponding alternative DHCP options for name resolution.

If a client now wants to access a server resource, it first queries the protected DNS server. If the policy stored there allows the target server, the client receives a positive DNS response. Due to the link with the Windows Filtering Platform, communication to the target server is permitted on the client as a result of the response.

If the client receives a negative DNS response or attempts to establish communication relationships with server services without DNS resolution or DNS servers from applications and addresses not contained in the IP whitelist, these queries are blocked locally. Administrators can define DNS-based filters. Client authentication certificates are used to identify the requesting client.

Increased complexity

As a result of the standard blocking, some services cannot function correctly due to the system itself. Printers would either have to be allowed via IP whitelisting or addressed via Microsoft's Universal Print with name resolution. Windows updates can no longer be distributed locally peer-to-peer, as this communication has not been enabled via DNS. Updates can only be distributed via WSUS or the new Microsoft Connected Cache for Enterprise and Education.

Collaboration platforms such as MS Teams, Webex and Zoom also pose challenges: These determine the destination addresses of audio and video streams via the STUN and TURN protocols and not via DNS. The same applies to classic IP telephony, where the address information is exchanged in the Session Description Protocol (SDP) within the signaling. IP whitelisting is required for both examples.

Wireless streaming to screens is problematic because, according to Microsoft, it simply won't work with this technology. A WLAN infrastructure with captive portals, such as in a hotel or train, is another problem area, as these usually intercept DNS data traffic and redirect destinations. Microsoft refers to this as an "unsupported scenario". DNS settings in the browser or in other applications must also be deactivated.

According to Microsoft, VPN clients that find their tunnel endpoint via secure DNS resolution or are included in the IP whitelist can communicate unhindered within the tunnel. The same applies to Hyper-V VMs and the WSL.

Conclusion

The approach seems both exciting and scary at the same time. Especially for WLAN environments with a captive portal, Microsoft will still have to develop a solution to ensure the acceptance of ZTDNS. Otherwise, it could result in a placebo effect, with all or most of the IP addresses ending up in the whitelist. At the same time, it does not make TLS inspection unnecessary, as no user data can be checked using DNS-based filters alone. Only the SNI-based filter is omitted. This raises whether ZTDNS represents over-engineering and is intended to drive customers away from third-party DNS products so that Microsoft cannot withhold the "exciting DNS information". According to Microsoft, admins can also only block or allow entire servers as targets. The respective services behind them cannot be regulated in this way.

All details on ZTDNS can be found in the Tech Community blog post.

(olb)