DNS over HTTPS and DNS over TLS: Encrypted DNS Deployment

DNS is the last plaintext protocol most enterprises still run on the wire, which means every internal lookup is visible to anyone on the path. DNS over TLS (DoT) and DNS over HTTPS (DoH) fix that, but they solve different problems: DoT is a clean drop-in for stub-to-resolver traffic on port 853, while DoH blends into HTTPS on 443 and is much harder to control from the network side. Choosing between them is a policy decision as much as a technical one.

DoT vs DoH at a Glance

• DoT - DNS over a dedicated TLS connection on TCP 853. Easy to identify, easy to rate limit, easy to block or allow at the firewall. Latency is low thanks to connection reuse and out-of-order pipelining.
• DoH - DNS as HTTPS requests to a URL template such as https://resolver.example/dns-query. Indistinguishable from web traffic, which is the point: it works through captive portals and hostile networks, and it is also impossible to police without TLS inspection.
• Both - neither encrypts the SNI or the server IP by default, so an on-path observer still learns which resolver you use. ECH and ODoH close that gap but are not widely deployed.

Server Side: DoT with Unbound

server:
    interface: 0.0.0.0
    interface: ::0
    access-control: 10.0.0.0/8 allow
    tls-port: 853
    tls-service-key: /etc/unbound/tls/server.key
    tls-service-pem: /etc/unbound/tls/server.crt
    tls-ciphers: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
    tls-session-ticket-keys: /etc/unbound/tls/ticket.key
    tls-use-sni: yes

unbound-control status | grep tls
openssl s_client -connect 10.0.0.53:853 -servername dns.example.com -tls1_3
kdig -d @10.0.0.53 +tls-ca +tls-hostname=dns.example.com example.com

The certificate must be signed by a CA your clients trust, and the name in the certificate must match either the resolver IP (via a SAN) or the hostname clients use. A DoT server with a self-signed certificate will simply be rejected by Android and modern Windows clients.

Server Side: DoH with a Reverse Proxy

# nginx in front of an unbound instance listening on 127.0.0.1:8053
location /dns-query {
    proxy_pass http://127.0.0.1:8053/dns-query;
    proxy_http_version 1.1;
    proxy_set_header Content-Type application/dns-message;
    proxy_set_header Accept application/dns-message;
}

# verify the wire format (RFC 8484 GET form, base64url-encoded query)
curl -s 'https://dns.example.com/dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' \
  -H 'accept: application/dns-message' | xxd | head

Both GET with a base64url-encoded query and POST with an application/dns-message body are defined by RFC 8484; support both, since different clients prefer different forms.

Client and Firewall Planning

• Windows 11 and Android support DoH natively; Linux mostly uses a local stub (systemd-resolved or unbound) that forwards over DoT.
• If your policy is to keep lookups inside the enterprise, block outbound TCP/UDP 853 to non-approved resolvers and block known public DoH endpoints by IP and path - then provide your own DoH endpoint so friendly clients still work.
• Stub resolvers should fail over to a second internal resolver, never to a public one; a silent fallback to 8.8.8.8 bypasses RPZ, logging and split-horizon entirely.
• Encrypted transport does not validate answers; keep DNSSEC validation enabled on the recursive resolver.

Related: Unbound DNSSEC validation setup, dig and nslookup troubleshooting, and PowerDNS and dnsdist load balancing when you need encrypted DNS at scale in front of several resolvers.

Testing and Rollout Order

# client-side checks
kdig +tls @10.0.0.53 example.com          # DoT
curl -s -H 'accept: application/dns-message' \
  'https://dns.example.com/dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | xxd | head
resolvectl status | grep -i 'DNS over\|protocol'

• Roll out to a pilot group first, on a network where the resolver is controlled, and watch query latency - connection setup to a remote resolver costs more than to a local one.
• Keep a plain DNS path to your own resolver available during the pilot; encrypted DNS, misconfigured, produces timeouts that look like a dead network.
• Publish the DOH/DoT endpoint internally before blocking third-party ones, or clients will simply bypass your logging.
• Document the SNI and endpoint addresses that are permitted through the firewall, and review them when the resolver changes.

原文链接：https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/ ｜ RFC 8484