RFC 9460: Enhancing Web Experience
RFC 9460: Advanced DNS Solutions and Enhanced Web Experience
The adoption of RFC 9460 is a significant milestone in the evolution of internet connectivity. This RFC introduces two new DNS record types: "SVCB" (Service Binding) and "HTTPS". These records promise to streamline the way browsers connect to websites, offering notable 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 APLN (Application-Layer Protocol Negotiation) during the HTTPS handshake.
This existing model, while secure, is not optimal. It involves multiple round trips, impacting the Time to First Byte (TTFB) and overall user experience. Moreover, load balancing and failover mechanisms aren't as efficient as they could be. RFC 9460 changes this by allowing the DNS to provide all necessary connection details. This method reduces the steps involved in establishing a secure connection, thereby significantly lowering the TTFB.
The Impact of SVCB and HTTPS Records
SVCB and HTTPS records bring notable changes. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS. This change quickens web connections significantly. 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. Further, they remove the need for HSTS preloading, streamlining secure connections. Most importantly, they enhance privacy with Encrypted Client Hello (ECH), formerly ESNI.
Adoption and Industry Response
The industry is adopting these records, even though they've only recently emerged from draft status. 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 in its early stages 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 of the limitations of DNS has been 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 such conflicts. This functionality is crucial for efficient content delivery networks (CDNs) and load balancing strategies.
These records enhance capability
1. Load Balancing:
Consider a website that wants to distribute traffic across multiple servers for efficiency. The 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 be configured with failover in mind:
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. In case of its failure, the system automatically falls back to backup-service.example.com.
3. Apex Domain Usage:
A major advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is crucial 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 the provision of keys for Encrypted ClientHello, which enhances 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 wanting to direct clients to more efficient or newer 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 directly connect using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.
The Long Wait
HTTPS has been around for a while, so why did it take so long for RFC 9460 to come into play? Apex records have had their share of problems, like not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.
Seriously, why did it take this long? 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.
A big shout-out to the creators of RFC 9460 for the initiative to get this through and obtain browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies
Conclusion
RFC 9460's SVCB and HTTPS records are not just incremental improvements; they're significant advancements in DNS technology. By enabling more precise control over how clients interact with servers, these records pave the way for improved performance, reliability, and security in web services. Their adoption promises to bring a new era of internet connectivity, benefiting both service providers and end-users alike.