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

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) are the two dominant protocols for encrypting Domain Name System traffic, addressing a structural plaintext vulnerability that has persisted since DNS was standardized by the Internet Engineering Task Force (IETF) in 1987. Both protocols wrap DNS queries in encrypted transport, but their architectures, port assignments, and deployment implications diverge in ways that matter for enterprise network operations, compliance auditing, and regulatory alignment. This page describes the definition and scope of encrypted DNS, the mechanical operation of each protocol, the professional contexts in which they are deployed, and the decision factors that determine which protocol fits a given operational environment. Coverage is oriented toward US-relevant deployment and compliance frameworks, and complements the broader encryption service landscape documented across this resource.

Definition and scope

The Domain Name System resolves human-readable hostnames into numeric IP addresses. In its baseline configuration, DNS queries and responses travel over UDP port 53 in plaintext, meaning any network intermediary — an ISP, an enterprise router, a rogue access point, or a nation-state actor — can observe, log, tamper with, or redirect the exchange. This exposure is not incidental; it is an architectural property of the original protocol design.

The NIST Cybersecurity Framework maps DNS interception risks to the Identify and Protect functions, treating unencrypted DNS as a confidentiality and integrity exposure. NIST SP 800-81-2, Secure Domain Name System (DNS) Deployment Guide, addresses DNS infrastructure hardening as a federal security baseline requirement and is maintained by the National Institute of Standards and Technology.

Encrypted DNS encompasses two IETF-standardized protocols:

• DNS-over-TLS (DoT) — standardized in RFC 7858 (2016), transmits DNS queries over a dedicated TLS-encrypted TCP connection on port 853.
• DNS-over-HTTPS (DoH) — standardized in RFC 8484 (2018), encapsulates DNS queries inside HTTPS traffic on TCP port 443, making the DNS payload indistinguishable from standard web traffic.

A third emerging variant, DNS-over-QUIC (DoQ), is specified in RFC 9250 (2022) and uses the QUIC transport protocol on UDP port 853, though enterprise adoption remains limited compared to DoH and DoT. The scope of this page covers the two dominant deployed protocols. For the broader encryption compliance landscape, see .

How it works

Both protocols share a common underlying mechanism: DNS query payloads are encrypted before transmission using TLS, preventing passive observation of the domain names being resolved. The differentiation lies in transport architecture and network visibility.

DNS-over-TLS (DoT) — Operational Sequence:

Because DoT uses a dedicated port (853), network administrators can explicitly monitor, filter, or block it. This distinguishability is a feature for enterprise environments that need to enforce DNS policies and log query traffic for Security Operations Center (SOC) visibility.

DNS-over-HTTPS (DoH) — Operational Sequence:

1. Responses are returned as HTTP responses with MIME type application/dns-message.

Because DoH traffic is syntactically identical to HTTPS web traffic on port 443, it cannot be distinguished from ordinary web browsing at the network layer without deep packet inspection. This blending property has implications for both user privacy and enterprise policy enforcement that are addressed in the decision boundaries section below.

Common scenarios

Encrypted DNS deployments arise across four distinct professional contexts:

Consumer and endpoint privacy. Operating systems including Windows 11 and Android 9 have native DoH support, allowing end-user devices to route DNS queries through a public encrypted resolver (such as those operated by Cloudflare at 1.1.1.1 or Google at 8.8.8.8 under their respective published privacy policies) rather than an ISP-assigned resolver. This disrupts ISP-level DNS logging practices.

Enterprise network security. Regulated industries — including healthcare entities subject to HIPAA (45 CFR §164.312(e)(1)) and financial institutions subject to GLBA Safeguards Rule requirements — deploy DoT internally to encrypt DNS traffic between internal resolvers while preserving administrative visibility on port 853. The CISA guidance document Encrypted DNS Implementation Guidance recommends that federal agencies evaluate DoH and DoT as part of zero trust architecture transitions per Executive Order 14028.

Mobile and remote workforce. VPN deployments that terminate at a corporate DNS resolver frequently supplement tunneled traffic with DoT to prevent DNS leakage when split-tunnel configurations are in use. RFC 8310 specifies authentication profile requirements for DoT in such deployments.

DNS Security Extensions (DNSSEC) integration. Neither DoH nor DoT replaces DNSSEC. DNSSEC (standardized in RFC 4033) provides cryptographic validation of DNS record authenticity, while DoH and DoT provide confidentiality for the transport channel. The two mechanisms are complementary, and NIST SP 800-81-2 recommends deploying both in federal environments.

Decision boundaries

Choosing between DoH and DoT is not primarily a security question — both provide equivalent TLS-grade encryption — but an operational and governance question. The following factors define the decision boundary for enterprise and compliance-driven deployments:

Network observability requirement. Environments where DNS query logging is a compliance obligation (SOC 2 Type II audit requirements, PCI DSS Requirement 10.2.4 under PCI DSS v4.0) should favor DoT. Its dedicated port 853 allows firewall and SIEM tools to intercept, log, and inspect queries without breaking encryption at the resolver level. DoH on port 443 defeats perimeter-level DNS inspection unless the organization operates its own DoH resolver.

Policy enforcement and filtering. Enterprise DNS filtering — blocking malicious domains, enforcing acceptable use policies, or applying split-horizon DNS — depends on routing all client queries through a controlled resolver. DoH clients configured to use public resolvers (bypassing the enterprise resolver) break this enforcement chain. Blocking port 443 is not operationally viable, so organizations relying on DNS-layer security must either deploy an internal DoH resolver or enforce DoT as the approved protocol.

Compatibility and deployment complexity. DoT requires client-side support for port 853 connections, which may not be present in legacy IoT devices or embedded systems. DoH, using standard HTTPS, has broader native support across modern operating systems and browsers — Mozilla Firefox enabled DoH by default in the United States in 2020 — making it the lower-friction option for heterogeneous endpoint fleets.

Zero trust alignment. CISA's Zero Trust Maturity Model (Version 2.0, published 2023) identifies encrypted DNS as a network pillar control. In zero trust architectures where all traffic is treated as untrusted, DoH aligns more naturally with the principle of encrypting all application-layer communications uniformly, while DoT's dedicated port is easier to explicitly authorize in micro-segmentation policies.

For organizations navigating these tradeoffs within a broader cryptographic compliance program, the How to Use This Encryption Resource page describes the reference structure available across this domain.