DNS-over-HTTPS (DoH) vs. DNS-over-TLS (DoT): Enterprise Security Implications

1. The Architectural Shift From Cleartext UDP/53 to Encrypted Transport

For nearly four decades, the Domain Name System operated almost exclusively over unencrypted UDP and TCP port 53 (RFC 1035). While DNSSEC (RFC 4033) introduced cryptographic signatures to verify authenticity and prevent cache poisoning, DNSSEC explicitly does not encrypt the query payload. Anyone positioned along the network path—public Wi-Fi operators, residential ISPs, or autonomous system (AS) adversaries—can passively harvest every hostname an endpoint resolves.

To close this privacy gap, the IETF standardized two encrypted transport protocols: DNS-over-TLS (DoT, RFC 7858) and DNS-over-HTTPS (DoH, RFC 8484). While both protocols wrap DNS wire-format messages inside TLS 1.3 encryption, their transport-layer design creates vastly different operational trade-offs for enterprise network engineers and managed service providers.

2. Protocol Mechanics: Dedicated Port 853 vs. Multiplexed Port 443

Understanding the packet-level distinction between DoT and DoH is essential before designing firewall egress policies or debugging split-horizon DNS failures.

Protocol Comparison Matrix

3. Why Unmanaged Browser DoH Breaks Agency & Enterprise Environments

When a web browser automatically upgrades to an external public DoH resolver (such as https://cloudflare-dns.com/dns-query or https://dns.google/dns-query), it bypasses the local operating system's /etc/resolv.conf and DHCP-assigned DNS servers entirely. This creates three severe operational issues:

1. Split-Horizon & VPN Resolution Failures: Internal staging environments (e.g., staging.internal.clientdomain.com) that only exist on private AWS Route53 Private Hosted Zones return NXDOMAIN when queried against public external DoH resolvers.
2. Bypass of Protective DNS & RPZ Filtering: Corporate DNS firewalls (Cloudflare Gateway, Cisco Umbrella, Route53 Resolver DNS Firewall) rely on intercepting recursive queries to block malware command-and-control (C2) domains and phishing links.
3. Loss of Forensic Incident Telemetry: SOC teams lose per-endpoint DNS query logs during incident investigations.

4. Controlling Encrypted DNS: DDR (RFC 9462) and Canary Domains

Rather than attempting to MITM-decrypt all port 443 traffic, modern network architects use two standardized discovery mechanisms to govern encrypted DNS cleanly:

1. Discovery of Designated Resolvers (DDR — RFC 9462)

By publishing an SVCB record under the special domain _dns.resolver.arpa, your local enterprise recursive resolver advertises its own authenticated DoH/DoT endpoint so endpoints upgrade to encrypted DNS without leaving your protective network boundary:

; Advertise internal DoT and DoH endpoints via RFC 9462 SVCB
_dns.resolver.arpa.  IN  SVCB  1  dns.corp.example.com. (
    alpn="h2,dot"
    port=853
    dohpath="/dns-query{?dns}"
)

2. Command-Line Diagnostics for DoT and DoH

Engineers can test and benchmark both DoT and DoH endpoints directly from the terminal using dig (BIND 9.18+) and curl:

# 1. Query a DNS-over-TLS (DoT) endpoint over TCP port 853
dig @1.1.1.1 +tls clientdomain.com SOA

# 2. Query a DNS-over-HTTPS (DoH) endpoint using RFC 8484 JSON/Wireformat
dig @1.1.1.1 +https=/dns-query clientdomain.com TXT

# 3. Verify browser canary domain response on your internal network
dig use-application-dns.net

5. Enterprise & Agency Network Verification Checklist

• ☐ Deploy internal encrypted DoT/DoH resolvers so endpoints gain TLS transport privacy without bypassing corporate Response Policy Zones (RPZ).
• ☐ Configure _dns.resolver.arpa SVCB records (RFC 9462) to enable automatic Discovery of Designated Resolvers.
• ☐ Block outbound TCP/853 to unauthorized external IP addresses at the perimeter firewall while permitting traffic to your designated protective resolvers.
• ☐ Verify split-horizon staging and production zones resolve identically across both standard and encrypted diagnostic probes using the DomainAfterCare DNS Inspector.