RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.
Understanding the Current Process
Traditionally, when a browser connects to a website, it follows a sequence:
- Browser requests site via HTTP.
- Server redirects request to HTTPS.
- Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.
The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.
The Impact of SVCB and HTTPS Records
SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.
Adoption and Industry Response
Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.
As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.
What the Records Look Like
A typical SVCB record might look like this:
_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")
This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.
An HTTPS record could be:
example.com. 3600 IN HTTPS 0 svc.example.net.
This record suggests that example.com should be accessed securely through svc.example.net.
Apex Domains and the Importance of SVCB/HTTPS Records
One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.
These records enhance capability
1. Load Balancing:
Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.
example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")
In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.
2. Failover Mechanism:
For a service that requires high availability, SVCB records can express failover directly:
critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")
Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.
3. Apex Domain Usage:
A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.
example.com. IN HTTPS 0 cdn-provider.example.net.
This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.
4. Encrypted ClientHello Support:
Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.
secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")
This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.
5. Directing Traffic to Specific Protocols:
For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.
api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")
Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.
The Long Wait
HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.
It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.
Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies
Final Thoughts
RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.
