Encrypted DNS: DNS-over-HTTPS and DNS-over-TLS Explained

Encrypted DNS protocols — specifically DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) — address a structural vulnerability in the Domain Name System that has existed since its standardization in 1983: DNS queries are transmitted in plaintext by default, exposing them to interception, manipulation, and surveillance. This page describes how both protocols function, their distinct technical architectures, the professional and regulatory contexts in which they are deployed, and the decision factors that determine which protocol fits a given environment. The scope covers US-relevant deployment, compliance frameworks, and sector-specific applicability.

Definition and scope

The Domain Name System resolves human-readable hostnames into IP addresses. In its baseline form, DNS traffic operates over UDP port 53 without encryption, allowing any network intermediary — an ISP, a Wi-Fi operator, or a malicious actor — to observe, log, or alter the query-response exchange. This exposure is classified as a threat to confidentiality and integrity under the NIST Cybersecurity Framework, which maps DNS interception to the Identify and Protect functions.

DNS-over-HTTPS (DoH) encapsulates DNS queries inside standard HTTPS traffic on TCP port 443, using TLS to encrypt the payload. It was standardized by the Internet Engineering Task Force (IETF) in RFC 8484 (2018).

DNS-over-TLS (DoT) wraps DNS queries directly in a TLS session on a dedicated TCP port 853, without the HTTP transport layer. It was standardized in RFC 7858 (2016).

Both protocols protect the DNS query payload from eavesdropping and prevent on-path modification of responses. Neither eliminates all metadata leakage — the IP address of the resolver is still visible to network observers — and neither substitutes for end-to-end application encryption handled at the TLS/SSL layer.

The distinction between DoH and DoT is architectural: DoH blends DNS traffic into the HTTPS stream, making it indistinguishable from ordinary web traffic; DoT uses a distinct, dedicated port that allows firewall identification and policy enforcement.

How it works

Both protocols depend on an underlying TLS handshake. The behavior of that handshake — certificate validation, cipher negotiation, and key exchange — is governed by the same standards described in the TLS/SSL encryption protocols reference and is subject to FIPS 140-3 validation requirements in federal deployments (NIST FIPS 140-3).

DNS-over-HTTPS (DoH) — operational sequence:

  1. The client establishes a TLS connection to the DoH resolver on port 443, validating the server certificate against a trusted certificate authority.
  2. The DNS query is formatted as an HTTP GET or POST request with the content type application/dns-message.
  3. The HTTPS response carries the DNS answer, encrypted within the TLS session.
  4. Because the traffic uses port 443, it is syntactically identical to browser HTTPS traffic; standard deep-packet inspection cannot differentiate it without decryption.

DNS-over-TLS (DoT) — operational sequence:

  1. The client opens a TLS session to the resolver on TCP port 853, completing a certificate handshake.
  2. DNS wire-format messages are transmitted within the encrypted TLS tunnel, without an HTTP framing layer.
  3. Network monitoring tools can identify DoT traffic by port number, enabling explicit allow/deny policies without full decryption.
  4. Persistent connections (session resumption) reduce latency overhead on subsequent queries.

Resolver authentication in both protocols depends on public key infrastructure and digital certificates issued by recognized certificate authorities. A compromised or misconfigured certificate chain negates the integrity guarantees of either protocol.

Common scenarios

Enterprise network management. IT security teams in regulated industries deploy DoT on port 853 because its dedicated port allows firewall administrators to enforce DNS policy — blocking unauthorized resolvers, logging query volumes, or routing traffic through internal resolvers — while still encrypting the query payload. The explicit port is an operational control point.

Browser-level privacy protection. Browsers including Firefox (via Mozilla's Trusted Recursive Resolver program) and Chrome implement DoH at the application layer, bypassing the operating system's configured resolver. This model prioritizes user privacy but creates a split-horizon problem in enterprise environments: device-level DNS policy may be circumvented by browser-level DoH, requiring organizations to explicitly block port 443 traffic to known public DoH resolvers or manage DoH via MDM policy.

Federal agency compliance. The Cybersecurity and Infrastructure Security Agency (CISA) issued guidance through its Protective DNS program, recommending encrypted DNS adoption as part of zero-trust architecture implementation. Agencies operating under OMB Memorandum M-22-09 must align DNS security with zero-trust network access principles.

Healthcare and financial sector deployments. Organizations subject to HIPAA or PCI DSS requirements treat unencrypted DNS as a transmission risk. HIPAA encryption requirements do not mandate a specific DNS protocol, but encrypted DNS reduces exposure of domain query data that could reveal protected health information access patterns. PCI DSS encryption requirements similarly treat network-level encryption holistically, encompassing DNS traffic in cardholder data environments.

Decision boundaries

Choosing between DoH and DoT — or retaining unencrypted DNS in specific network segments — involves discrete architectural trade-offs rather than a single correct answer.

Factor DoH DoT
Port 443 (shared with HTTPS) 853 (dedicated)
Network visibility Traffic blends with HTTPS; policy enforcement requires decryption Port-identifiable; firewall-enforceable without decryption
Enterprise control Lower (browser-level bypass possible) Higher (explicit port blocking/routing)
Latency profile Slightly higher (HTTP framing overhead) Lower (direct DNS-in-TLS)
IETF standard RFC 8484 (2018) RFC 7858 (2016)
Browser native support Broad (Chrome, Firefox, Edge) Limited (OS and resolver level)

When DoT is preferred: Environments requiring explicit DNS policy enforcement — corporate networks, government segments, healthcare infrastructure — favor DoT because network security tooling can identify, log, and control port 853 traffic without performing full TLS inspection. This aligns with the principle of maintaining audit trails required under frameworks like NIST SP 800-53 Rev 5, Control AU-12 (NIST SP 800-53).

When DoH is preferred: Consumer-facing applications, browser vendors, and service providers prioritizing privacy from network-level observers — including ISPs — deploy DoH because the port-443 blending prevents selective blocking or throttling of DNS traffic.

When neither is sufficient alone: Encrypted DNS protects the client-to-resolver channel. It does not protect the resolver-to-authoritative-server leg of the query, which may still traverse plaintext paths. Full DNS security requires pairing encrypted DNS with DNSSEC (RFC 4033), which authenticates DNS responses via cryptographic signatures — a separate but complementary control. Organizations managing cryptographic assets across the DNS stack should also review encryption key management practices governing resolver certificates and DNSSEC signing keys.

A third variant, DNS-over-QUIC (DoQ), standardized in RFC 9250 (2022), transmits DNS over the QUIC transport protocol, reducing connection-establishment latency. DoQ is not yet in widespread production deployment but represents the direction of IETF standards development for encrypted DNS.

References

Explore This Site

Regulations & Safety Regulatory References