DNS over HTTPS: Encrypted DNS Resolution

Every website you visit begins with a DNS query—a plaintext request transmitted over UDP port 53 that reveals exactly which domains you're accessing. Your ISP sees every query. Network operators at cafes, hotels, and airports see every query. Governments conducting surveillance see every query. Even with HTTPS encrypting your actual web traffic, DNS queries create a detailed log of your internet activity.

DNS over HTTPS (DoH) fundamentally changes this dynamic by wrapping DNS queries inside encrypted HTTPS connections. To network observers, DoH traffic is indistinguishable from regular HTTPS web traffic—just another connection to a server on port 443. This provides genuine privacy for DNS resolution while also bypassing network-level DNS manipulation and censorship.

To understand why DoH exists, we must first understand the privacy and security implications of unencrypted DNS. Traditional DNS (RFC 1035) was designed for a cooperative, academic network where privacy was not a concern. Today's internet reality is fundamentally different.

What traditional DNS exposes:

1. Every domain you query — Including domains you don't ultimately visit (typos, blocked sites, failed lookups)
2. Query timing patterns — When you're active online, which hours you browse, activity patterns
3. Application behavior — Many apps leak information through distinctive DNS query patterns
4. Location correlation — DNS queries from your IP address tie activity to your physical location
5. Cross-device profiling — All devices on a network share the same resolver, enabling household profiling

Beyond privacy—integrity concerns:

Unencrypted DNS also enables manipulation:

• ISP redirection — Some ISPs redirect failed DNS lookups to ad-filled "helper" pages
• Captive portal injection — Networks intercept DNS to force portal login flows
• Censorship implementation — Governments mandate ISP DNS lying to block access to sites
• Malware C2 blocking — Enterprise networks may block known malware domains at DNS level
• Ad injection — Malicious networks redirect DNS to inject advertisements

While some manipulation is benign or even desired (enterprise security), the mechanism enables both legitimate uses and abuse. DoH shifts control from network operators to users.

DNS over HTTPS (RFC 8484) encapsulates DNS messages within HTTPS requests and responses. Unlike traditional DNS which uses its own UDP/TCP-based transport, DoH leverages the existing web infrastructure—TLS encryption, HTTP/2 multiplexing, and standard web server technology.

Core design principles:

1. Use standard HTTPS — DoH uses regular HTTPS on port 443, making it indistinguishable from web traffic
2. Preserve DNS wire format — The actual DNS query/response uses the standard binary format from RFC 1035
3. Support HTTP semantics — Both GET (cacheable) and POST (for larger queries) methods work
4. Leverage HTTP/2 — Connection multiplexing enables multiple queries over one connection
5. Enable caching — Proper HTTP cache headers allow intermediary caching of responses

URI Template and Content Types:

DoH servers expose an endpoint (typically /dns-query) that accepts DNS queries. The RFC specifies:

• Content-Type: application/dns-message — The body contains raw DNS wire format
• Accept header: Client indicates it wants application/dns-message responses
• URI Template: Servers advertise their endpoint via URI template (e.g., https://dns.example.com/dns-query{?dns})

GET vs POST methods:

• GET: Query encoded as base64url in dns parameter; cacheable by HTTP intermediaries; limited by URL length
• POST: Query in request body; works for any query size; typically not cached; used for most implementations

HTTP/2 advantages:

DoH strongly benefits from HTTP/2 features:

• Multiplexing — Multiple DNS queries share one TLS connection without head-of-line blocking
• Header compression (HPACK) — Reduces overhead for repeated queries to same resolver
• Server push (potential) — Resolver could push anticipated records (rarely implemented)
• Connection reuse — Amortizes TLS handshake cost across many queries

One of DoH's practical challenges is resolver discovery—how does a client know which DoH server to use? Traditional DNS resolvers are discovered automatically via DHCP. DoH requires explicit configuration or discovery mechanisms.

Current configuration methods:

1. Manual configuration — User explicitly enters DoH resolver URL in browser/OS settings
2. Browser defaults — Firefox, Chrome use built-in DoH resolver lists (often Cloudflare, Google, NextDNS)
3. OS integration — Windows 11, macOS, iOS have system-level DoH support
4. DDR (Discovery of Designated Resolvers) — RFC 9462 automatic upgrade mechanism

The DDR protocol:

Discovery of Designated Resolvers enables automatic DoH/DoT upgrade. Clients query a special DNS record type (SVCB/HTTPS) to discover encrypted resolver endpoints:

1. Client connects to DHCP-provided resolver via traditional DNS
2. Client queries _dns.resolver.arpa SVCB record
3. If present, record contains DoH/DoT endpoint information
4. Client verifies TLS certificate matches expected resolver identity
5. Client upgrades to encrypted resolver automatically

Browser behavior and fallback:

Modern browsers implement DoH with careful fallback behavior:

Firefox:

• Uses DoH by default in some regions (US initially)
• Falls back to traditional DNS if DoH fails
• Detects captive portals and enterprise networks, disables DoH
• Checks for canary domain to detect network-level DoH blocking

Chrome/Edge:

• Upgrades to DoH if current resolver has known DoH endpoint
• Doesn't change resolver choice, only transport encryption
• Prefers system DNS resolver if configured

Safari/iOS:

• System-level DoH configuration in iOS 14+/macOS 11+
• Apps can specify per-app DoH requirements
• Enterprise MDM can control/disable DoH

A common concern with DoH is performance overhead—TLS handshakes and HTTP framing add latency compared to raw UDP. However, real-world performance is more nuanced, and DoH can actually improve resolution times in some scenarios.

Latency components:

Traditional DNS (UDP):

• Single RTT for query + response
• No encryption overhead
• No connection state to maintain
• Total: ~1 RTT per query

DoH (initial connection):

• TCP handshake: 1 RTT
• TLS 1.3 handshake: 1 RTT
• HTTP/2 SETTINGS exchange: 0 RTT (piggybacked)
• DNS query/response: 1 RTT
• Total: ~3 RTT for first query

DoH (subsequent queries, same connection):

• Connection already established
• DNS query/response: 1 RTT
• HTTP/2 multiplexing avoids head-of-line blocking
• Total: ~1 RTT per query

When DoH is faster:

Surprisingly, DoH can outperform traditional DNS in several scenarios:

1. Unreliable networks — TCP's reliability prevents the need for application-layer retries common with UDP DNS

2. Multiple queries — HTTP/2 multiplexing sends many queries simultaneously; traditional DNS serializes queries

3. Well-connected resolvers — Cloudflare/Google have extensive PoP networks; your ISP's resolver may be farther

4. TLS 1.3 session resumption — Pre-shared keys enable 1-RTT connections (0-RTT with early data)

5. Connection warming — Browsers proactively establish DoH connections during idle time

Performance optimization strategies:

• Connection persistence — Keep DoH connections alive; avoid repeated TLS handshakes
• HTTP/2 multiplexing — Bundle multiple queries on single connection
• TLS session tickets — Enable fast session resumption for new connections
• HTTP/3 adoption — QUIC's 0-RTT significantly reduces cold-start latency
• Local caching — Respect DNS TTLs; avoid redundant queries

DoH has been controversial within the internet governance community. While proponents emphasize privacy benefits, critics raise concerns about DNS centralization and the shifting power dynamics in internet infrastructure.

The centralization argument:

Traditional DNS resolution is distributed by design—thousands of ISPs operate resolvers, and users typically use their ISP's resolver automatically. DoH, by enabling easy resolver switching and requiring explicit configuration, tends to concentrate queries on a few large providers:

• Cloudflare (1.1.1.1) — Firefox default, wide adoption
• Google (8.8.8.8) — Chrome integration, Android default
• Quad9, NextDNS, AdGuard — Smaller but growing share

This concentration creates new points of control, surveillance potential, and single points of failure.

Enterprise and network operator concerns:

Network administrators have expressed significant concerns about DoH bypassing their visibility and control:

1. Security monitoring — Enterprise security often relies on DNS logging to detect malware, C2 communication, and data exfiltration. DoH bypasses these controls.

2. Content filtering — Schools, libraries, and workplaces use DNS for content filtering. DoH allows users to circumvent these policies.

3. Split-horizon DNS — Enterprises often have internal DNS zones (e.g., intranet.company.com) that external DoH resolvers cannot resolve.

4. Incident response — DNS logs are crucial forensic evidence. DoH to external resolvers eliminates this visibility.

5. Regulatory compliance — Some industries require logging of all internet activity; DoH complicates compliance.

The balanced perspective:

Both sides have legitimate concerns:

• Users have genuine privacy interests that ISPs have historically violated
• Network operators have genuine security needs that DoH can undermine
• Centralization risks are real but may be mitigated by more DoH provider diversity
• Technical solutions (like DDR) can preserve operator control while enabling encryption

DoH and DNSSEC are complementary technologies that together address different DNS security needs. Understanding their relationship is essential for implementing comprehensive DNS security.

What each provides:

The complete security model:

To achieve full DNS security, combine both technologies:

1. DoH encrypts the path to the resolver — Your ISP cannot see or modify your DNS queries
2. DNSSEC validates the response authenticity — Even if the DoH resolver lies, DNSSEC validation detects it
3. Trust is minimized — You don't need to trust either network operators OR the DoH resolver

Implementation considerations:

Where should DNSSEC validation happen?

• At the resolver (common): The DoH resolver performs DNSSEC validation and returns an "AD" (Authenticated Data) flag if verified. Client trusts this flag.

• At the client (more secure): Client performs its own DNSSEC validation after receiving response. Doesn't trust resolver's AD flag. Requires DNSSEC-validating stub resolver.

DoH resolvers and DNSSEC:

Most major DoH providers perform DNSSEC validation:

• Cloudflare: Returns AD flag; SERVFAIL for BOGUS responses
• Google: Validates by default; provides DNSSEC status in responses
• Quad9: Strong DNSSEC stance; returns SERVFAIL for validation failures

Deploying DoH ranges from simple browser configuration to enterprise-scale infrastructure. Understanding deployment options helps choose the right approach for your needs.

Client-side deployment options:

Server-side / Enterprise deployment:

Organizations may want to deploy their own DoH servers to maintain control while providing encryption:

1. Internal DoH resolver — Run a DoH-enabled resolver (dnsdist, CoreDNS, nginx with dns-over-https module) internally. Clients configured to use internal DoH endpoint.

2. Split DNS with DoH — Internal resolver handles internal zones; forwards external queries to upstream DoH resolver.

3. DoH with logging — Deploy DoH internally but maintain DNS logging for security/compliance. Encryption protects from external observers, not internal.

4. DDR publishing — Publish SVCB records for resolver.arpa to enable automatic client upgrade to your DoH/DoT server.

Blocking DoH (network perspective):

Some networks legitimately need to prevent DoH bypass:

• Block known DoH resolver IPs (continuously updated lists available)
• Deep packet inspection to detect DoH patterns (difficult, resource-intensive)
• Deploy enterprise canary domains that browsers respect
• Policy enforcement via MDM/GPO to disable browser DoH
• Certificate inspection (controversial; requires MITM proxy)