RFC 8484 — DNS over HTTPS
DNS Queries over HTTPS (DoH) — protocol for performing DNS resolution via HTTPS, providing confidentiality and integrity protection for DNS queries against eavesdropping and manipulation.
1. Introduction
▶DNS over HTTPS (DoH) encapsulates DNS queries and responses within HTTPS, providing the same confidentiality and integrity guarantees as any HTTPS traffic. This prevents network observers from seeing or manipulating DNS lookups.
ISO 27001 Relevance: A.8.20 (Network Security) — protects DNS as a critical network infrastructure component. A.8.21 (Security of Network Services) — encrypted DNS as a network service. A.8.24 (Use of Cryptography) — TLS encryption for DNS queries.
2. Protocol Design
▶- Transport: Standard HTTPS (port 443) — blends with normal web traffic
- Methods: HTTP GET (base64url-encoded query in URI) or POST (binary DNS message in body)
- Content-Type: application/dns-message
- Caching: HTTP cache semantics apply, using DNS TTL values
Client DoH Server (e.g., resolver)
┌────────┐ ┌──────────┐
│ App │── HTTPS ──> │ DNS │
│ Stub │ POST/GET │ Resolver│──> Upstream DNS
│ Resolver│<── HTTPS ── │ │
└────────┘ 200 OK └──────────┘
+ dns-message body 3. Security Benefits
▶| Threat | Traditional DNS | DoH |
|---|---|---|
| Eavesdropping | Visible in plaintext | Encrypted in TLS |
| Manipulation | No integrity check | TLS integrity |
| Censorship | Easy to filter | Blends with HTTPS |
| Tracking | All resolvers see queries | Only DoH server sees queries |
4. Security Considerations
▶- Resolver trust: DoH shifts trust from the network path to the DoH resolver — choose a trusted resolver or run your own
- Enterprise visibility: DoH can bypass enterprise DNS monitoring — deploy internal DoH resolvers to maintain visibility (A.8.16)
- Split-horizon: Internal DNS resolution may need to bypass DoH for private namespaces
- DNSSEC validation: DoH does not replace DNSSEC (RFC 4033) — use both for defense in depth