RFC 8484

RFC 8484
Title	RFC 8484
Status	Final
Published	2018-10
Authors	Paul Hoffman, Patrick McManus
Category	Standards Track
Document	Request for Comments

RFC 8484 RFC 8484 defines a method for encapsulating DNS queries and responses in the Hypertext Transfer Protocol Secure transport layer by using the HTTP/2 framing and semantics. It specifies a mapping between the Domain Name System wire format and HTTPS requests so that DNS messages may be transported over TLS-encrypted HTTP connections, enabling privacy and middlebox traversal improvements while leveraging existing TLS and HTTP infrastructures.

Background and Motivation

The specification responds to privacy and deployment pressures arising from widespread passive monitoring exemplified by disclosures such as the Edward Snowden leaks and legislative actions like the Foreign Intelligence Surveillance Act debates. Operators and vendors sought mechanisms comparable to encryption efforts in protocols like SMTP STARTTLS and IMAP over TLS yet compatible with large-scale systems including Content Delivery Networks and Cloudflare-style reverse proxies. Prior work on encrypted name resolution, including proposals from IETF working groups and experiments by vendors such as Google and Mozilla, motivated a standard that interoperates with existing TLS ecosystems and leverages headers and framing from HTTP/2 to minimize middlebox interference typical of legacy ports such as those used by DNS over TLS and classic UDP/TCP DNS.

Specification

RFC 8484 specifies that DNS messages in wire format are carried as the body of HTTPS POST or GET requests using the media type application/dns-message and appropriate HTTP/2 stream semantics. The document lays out required and optional HTTP headers, such as Content-Type and Accept, and normative behaviors for status codes including HTTP 200 OK and client-redirect handling like HTTP 503 Service Unavailable or HTTP 301 Moved Permanently when acting with intermediaries such as reverse proxyes or load balancers. The mapping requires maintenance of two canonical transport identifiers: the original DNS QNAME encoding and the wire-format DNS header fields, and it prescribes methods for content-length framing, response caching directives compatible with CDN caching policies, and content negotiation behaviors consistent with HTTP/1.1 and HTTP/2 intermediaries.

Protocol Operation and Examples

Operation examples include a client constructing a POST request to an authoritative resolver or recursive resolver endpoint with the DNS question encoded in the request body, and a server returning the DNS message payload with appropriate cache-control headers. The specification illustrates interactions where clients use HTTP methods and TLS handshake negotiation including Server Name Indication to select resolvers hosted by providers such as Google Public DNS or Quad9, and where intermediaries like Akamai or Fastly handle TLS termination. Example flows show error handling when servers respond with HTTP 301 Moved Permanently for endpoint migration, or when HTTP/2 stream resets occur during QUIC-based evolution. The text also demonstrates how existing resolver features, such as EDNS(0) options and DNSSEC signatures, are preserved in the DNS wire payload and how clients and servers should handle truncated responses and fallbacks to TCP or traditional DNS over UDP.

Security Considerations

Security discussion centers on threat models involving on-path observers and active adversaries, referencing adversarial scenarios addressed in TLS 1.2 and TLS 1.3 specifications and mitigations deployed by browsers like Mozilla Firefox and Google Chrome. It analyzes risks from TLS termination by intermediaries such as enterprise proxy appliances and CDN operators, and stresses the importance of certificate validation against X.509 trust anchors and revocation mechanisms like Certificate Transparency. Considerations also include potential amplification vectors when DNS over HTTPS endpoints are exposed, denial-of-service risks familiar from SYN flood and HTTP Pipelining abuse, and guidance on deployer responsibilities comparable to those described in HTTP/2 security analyses. The specification defers to existing cryptographic recommendations in IETF TLS Working Group documents for key exchange, cipher suite selection, and record-layer protections.

Implementation and Adoption

Following publication, implementations quickly emerged from browser vendors and resolver operators; notable adopters include projects and organizations such as Mozilla, Google, Cloudflare, and Cisco. Libraries and clients integrated support in networking stacks that leverage nghttp2 and OpenSSL or BoringSSL backends, and operating systems and applications implemented resolvers that expose APIs consumed by applications like Firefox and mobile platforms from vendors like Apple and Google Android. Deployment patterns included both public recursive services and enterprise proxy services, with experimentation in content-delivery deployments by providers such as Akamai. Adoption involved coordination with standards bodies like the IETF DNSOP Working Group and ecosystem projects including getdns and Unbound.

Performance and Limitations

Performance trade-offs include increased connection overhead relative to UDP-based DNS due to TCP and TLS handshake latency, mitigated by HTTP/2 multiplexing and connection reuse techniques used by CDN and browser connection pools. Limitations include middlebox behavior that may alter HTTP headers, caching semantics that differ from traditional DNS caches, and complexity in supporting fallback mechanisms such as DNS over TLS or classic UDP resolvers in environments with strict egress filtering or legacy NATs. The specification acknowledges that while privacy against passive eavesdroppers improves, metadata in TLS SNI and HTTP host headers can still leak resolver selection without additional techniques like Encrypted Client Hello proposals or integration with DNS-over-QUIC evolutions, and it encourages further work on measurement studies and operational best practices.

Category:Internet standards