Abstract

DNS remains one of the highest-value targets for network-level surveillance and manipulation. Despite years of industry effort, most enterprise internal DNS traffic still travels in plaintext UDP. DNS over HTTPS (DoH) and DNS over TLS (DoT) provide authenticated, encrypted query channels, but enterprise deployment introduces constraints absent in consumer contexts: split-horizon DNS, internal resolvers, endpoint MDM coverage, and the need to preserve DNS visibility for security monitoring. Threading these requirements is achievable with the right architecture.

Protocol Selection and Resolver Infrastructure

DoT (RFC 7858) and DoH (RFC 8484) offer different integration profiles. DoT operates on a dedicated port (853) and is easier to allow-list and monitor at the network layer; DoH uses port 443, making it harder to distinguish from HTTPS and simpler to deploy through HTTP infrastructure. For enterprise use, DoT’s visibility advantage generally outweighs DoH’s firewall-traversal benefit. QUIC-based DNS over QUIC (DoQ, RFC 9250) is gaining traction in 2025 and offers lower latency than DoT on lossy links.

Internal resolver infrastructure should run encrypted-capable resolvers such as Unbound or PowerDNS Recursor, both of which support DoT on the listening side as of their current stable releases. Deploying dedicated resolver pools by segment - one for corporate endpoints, one for production workloads - keeps query logs separated and simplifies policy enforcement. Quad9, Cloudflare 1.1.1.1, and Google 8.8.8.8 all support DoT and DoH for external resolution, but internal zones must resolve through the internal resolver first, with external queries forwarded from there.

Client Enforcement via MDM

For managed endpoints, enforcing encrypted DNS requires MDM configuration profiles. On macOS, a com.apple.dnsSettings.managed payload configures DoH or DoT system-wide, overriding resolver settings from DHCP. On Windows, the encrypted DNS settings introduced in Windows 10 21H1 can be deployed via Group Policy or Intune. Linux endpoints require either systemd-resolved with DNSOverTLS=yes or local stub resolvers such as dnscrypt-proxy.

A common gap is BYOD and contractor devices. Network-level enforcement - blocking UDP/TCP 53 except from managed resolver IPs - pushes unmanaged devices toward the designated resolver without requiring MDM coverage. Devices that cannot negotiate DoT with the internal resolver fall back to the network-enforced resolver, and all plaintext queries from outside the allowed set are dropped.

Preserving Security Visibility

The primary concern raised when encrypting DNS is loss of visibility. DNS query logs are a tier-one signal for malware C2 detection, data exfiltration via DNS tunneling, and domain generation algorithm (DGA) traffic. Encrypted DNS does not eliminate this visibility - it relocates it. When the resolver infrastructure is controlled by the security team, query logs are available at the resolver rather than from passive network capture. Resolver logging to a SIEM (via syslog or the RPZ passive DNS format) preserves the detection capability while removing the plaintext-on-wire exposure. Tools like PassiveDNS and Zeek’s dns.log can ingest resolver logs as an alternative to packet capture.