DNS Gets a New Job: Pre-Negotiating HTTP Connections
In mid-2020, Cloudflare's resolver team spotted an unusual surge in DNS queries for the 65479 Resource Record, traced back to Apple's iOS 14 beta. Apple was testing a new SVCB/HTTPS record type designed to move connection negotiation out of the HTTP layer and into DNS. Cloudflare rolled out support across its customer base during the beta period.
The result: Apple devices running iOS 14 with HTTP/3 enabled can now automatically determine the best way to reach any Cloudflare-protected website or API without any configuration changes from the site operator.
The Chicken-and-Egg Problem of HTTP Negotiation
When a browser receives a URL without an explicit scheme, it cannot assume HTTPS support exists unless it has prior knowledge from an HSTS cache or preload list. The browser typically makes an initial plaintext HTTP request, then waits for either an HTTPS redirect or an HSTS policy in the response before retrying over TLS.
This doubles latency for the first resource fetch, since the browser must re-establish the connection and request the resource again over a secure channel. Worse, the initial plaintext request is exposed on the network, leaving it vulnerable to on-path attackers who could modify the response for malicious purposes, such as injecting unwanted content on public WiFi networks.
The same issue impacts HTTP/3 adoption. HTTP/3 support is advertised via the Alt-Svc HTTP header, which only appears after the client has already connected using an older HTTP version. Browsers learn about HTTP/3 only on subsequent visits to a site, missing the protocol's performance benefits during the first connection.
The root cause: HTTP-related parameters like HTTPS and HTTP/3 support are negotiated through HTTP itself via redirects, HSTS, or Alt-Svc headers. This forces clients to start with the most basic configuration that is most likely to work—typically plaintext HTTP/1.1—and only upgrade after receiving additional parameters.
DNS resolution happens before any connection attempt, presenting an opportunity to embed connection-related information alongside IP addresses. Cloudflare has now implemented this: its DNS servers automatically generate HTTPS records on the fly, advertising whether a zone supports HTTP/3 and/or HTTP/2 based on the zone's feature configuration.
SVCB and HTTPS Record Formats
The IETF draft specification defines a family of DNS resource record types called "SVCB" for negotiating parameters across application protocols. The "HTTPS" instance is specific to HTTP and serves two purposes: signaling that a client can use a secure connection directly (bypassing the initial unsecured request) and advertising supported HTTP versions. Future extensions could advertise additional features.
example.com 3600 IN HTTPS 1 . alpn=”h3,h2”This record type is most effective when combined with DNS over HTTPS, DNS over TLS, and DNSSEC, which prevent malicious actors from tampering with the records.
Clients can fetch A, AAAA, and HTTPS records in parallel to avoid additional latency, but this creates a potential consistency issue. In scenarios involving DNS load-balancing or multiple CDNs, the A/AAAA responses might come from a different provider than the HTTPS record. This divergence can cause connection failures if, for example, the HTTPS record advertises HTTP/3 support from a CDN that the client ultimately connects to but which doesn't actually support the protocol.
The SVCB and HTTPS specifications address this through optional ipv4hint and ipv6hint parameters, which provide IP addresses directly within the record. Clients can use these hints instead of querying A and AAAA records separately. Although clients still need to fall back to A/AAAA queries when no SVCB or HTTPS record exists, the hints add a layer of robustness against divergent responses.
example.com 3600 IN HTTPS 1 . alpn=”h3,h2” ipv4hint=”192.0.2.1” ipv6hint=”2001:db8::1”These records also support alternative endpoints analogous to SRV records.
example.com 3600 IN HTTPS 1 example.net alpn=”h3,h2”
example.com 3600 IN HTTPS 2 example.org alpn=”h2”example.com HTTPS service is provided by both example.net (supporting HTTP/3, HTTP/2, and HTTP/1.x) and example.org (supporting HTTP/2 and HTTP/1.x). Clients would generally need to resolve A and AAAA records for the alternative endpoints before connecting, potentially increasing latency, though IP hint parameters can reduce the number of required DNS lookups. This finally brings SRV-like functionality to browsers and clients that have historically not supported SRV records.
A Cleaner Alternative to CNAME at the Apex
Websites commonly use a "www" subdomain as well as the apex domain. To avoid duplicating DNS configuration, the www subdomain is typically set up as a CNAME pointing to the apex record.
cloudflare.com. 3600 IN A 192.0.2.1
cloudflare.com. 3600 IN AAAA 2001:db8::1
www 3600 IN CNAME cloudflare.com.However, certain services such as GitLab Pages, GitHub Pages, or Netlify require users to manually add A (and sometimes AAAA) records with hard-coded IP addresses. If the provider changes those addresses for load-balancing or other reasons, every user must update their configurations.
Using a CNAME to a stable domain would solve this, but the DNS specification forbids additional records alongside a CNAME. Although this works for subdomains, apex records must carry SOA, NS, and often MX records, making CNAMEs at the apex problematic even when they appear to function.
SVCB and HTTPS records provide an "alias form" that behaves like a CNAME without the historical constraints. Domain operators can define a record like
example.com. 3600 IN HTTPS example.org.A Foundation for Encrypted ClientHello
Encrypted SNI, now termed "Encrypted ClientHello" (ECH), extends TLS to improve user privacy. Earlier specifications used a custom TXT record to advertise a server's public key share, which clients use to derive the secret key for encrypting the SNI. Newer revisions replace that TXT record with the echconfig parameter carried in SVCB and HTTPS records. SVCB/HTTPS support is therefore a prerequisite for adopting newer Encrypted ClientHello revisions.
Deployment Status and Client Adoption
Cloudflare has already enabled initial HTTPS record support across its edge network. DNS servers generate records on the fly, advertising HTTP/3 and/or HTTP/2 support based on zone configuration, with Encrypted ClientHello support planned.
Apple's iOS 14 includes client-side HTTPS record support, enabling connections to upgrade to QUIC when the HTTP/3 parameter is present. Apple reports that of users who manually enabled HTTP/3 on iOS 14, 8% of QUIC connections utilized the HTTPS record response. 
