DNS-over-HTTPS: practical operational implications

DNS-over-HTTPS (DoH) takes DNS queries that historically used UDP/53 and tunnels them through HTTPS to port 443. End users get encrypted DNS that survives most middleboxes. Network operators get a new set of operational problems.

Here’s what changed in practice.

What DoH is

A client sends a DNS query as either an HTTP GET or POST to a /dns-query endpoint. The query is wire-format DNS in the body. The response is wire-format DNS in the response body. TLS protects everything end-to-end.

Major recursors (1.1.1.1, 8.8.8.8, 9.9.9.9) all support DoH. Major browsers default to DoH for some configurations (Firefox uses Cloudflare unless you opt out, Chrome uses the system resolver if it supports DoH).

The protocol is RFC 8484. It’s not complicated.

What changes for end users

DoH defeats most of the historical mechanisms operators used to inspect or manipulate DNS:

Captive portals that intercept DNS to redirect users to a login page no longer work cleanly.
Parental controls based on DNS-level blocklists (Pi-hole, NextDNS) bypass-able by browsers using their own DoH.
Network-level malware blocking that works at DNS no longer covers DoH-using clients.

This is mostly a feature. Users get protection from network-level inspection (ISPs, public Wi-Fi). It is also a problem when the network operator legitimately needs to control DNS — schools, corporate networks, parental devices.

What changes for the recursor operator

Operationally, DoH is HTTPS. That means:

TLS certificates. Public DoH endpoints need valid certs from a public CA. Internal DoH endpoints need internal PKI. Cert renewal is a thing now.
HTTP server. You’re running an HTTP server in front of (or alongside) your DNS server. The major options: nginx as a reverse proxy in front of dns-over-https-proxy; built-in DoH support in the recursor (Unbound and Knot Resolver both support it).
Connection costs. UDP/53 is connectionless. HTTPS has TLS handshake overhead. For a recursor handling millions of queries, this is non-trivial.

Performance is interesting. Per-query latency increases (TLS handshake on first query, then 0-RTT or HTTP/2 multiplexing on subsequent queries). Throughput is lower because TLS terminates connections. Connection reuse via HTTP/2 mitigates most of this in steady state but the cold-start cost is real.

What changes for the network operator

DoH defeats network-level DNS inspection. If you run a network where DNS visibility matters — corporate, education, kids’ devices — your options are:

Block known DoH endpoints. Maintain a list of public DoH server IPs and DNS names, block at firewall. Possible but high-maintenance: new endpoints appear constantly, and clients fall back to DoH-on-port-443 from arbitrary endpoints.
MITM TLS. Issue your own internal cert, install it on managed devices, decrypt and inspect TLS. Standard corporate practice; requires device management.
Educate users / configure clients. Disable DoH in browser settings via group policy / MDM. Works for managed devices, doesn’t work for BYOD.
Accept the loss of visibility. This is the right answer for most networks where the cost-benefit doesn’t favor active interception.

The “encrypted DNS gives users privacy from their network operator” framing is correct. Whether you’re the operator who needs visibility or the operator who’s protecting users from a hostile network is a question of context.

What changes for an authoritative operator

Surprisingly little. Authoritative DNS is still queried by recursors, almost always via classic UDP/TCP on port 53. Recursors that support DoH (Cloudflare, Google) still talk to your authoritative server in plain DNS.

This will change eventually as the protocol matures, but for now, the authoritative side of DNS is unchanged by DoH adoption.

When to deploy DoH yourself

Three reasonable scenarios:

You operate a recursor for the public — provide DoH alongside UDP/53.
You operate an enterprise network and want to control where users’ DNS goes — run an internal DoH endpoint that resolves through your filtering, push the config to managed devices.
You operate a privacy-focused service and want clients to query you over DoH from anywhere — like Cloudflare, but smaller scale.

For most internal networks resolving through Active Directory or simple Unbound, DoH adds complexity without immediate benefit. Plan for it; don’t deploy it preemptively.

DoH is the future direction of recursive DNS. Authoritative DNS over UDP/53 is going to stay around for a long time.