For the past several years, the DNS operations group at the Internet Engineering Task Force (IETF) has been developing a pair of new record types known as ‘SVCB’ and ‘HTTPS’. In May, their specification was formally approved for publication by the Internet Engineering Steering Group (IESG). This milestone marks these new record types as ready for production use on the public Internet.
HTTPS and SVCB record types aim to change a long-standing paradigm
There are dozens of defined DNS record types, but the most common one is known as an ‘A’ record. It dates to the beginning of the DNS (around 1983) and contains an IPv4 address that can be used to reach the associated domain name. The ‘AAAA’ record (defined in 1995) is its counterpart for IPv6. Together, these two types are still the basis for most Internet usage. When you open a website, an SSH terminal, or almost any mobile app, your device will likely send only A and AAAA queries, to retrieve the IP addresses of the service it’s trying to reach.
The HTTPS and SVCB record types aim to change this long-standing paradigm. These record types encode a service binding, providing not only the IP addresses of the service but also any other information that could help the client during connection setup. Unlike A and AAAA, these records are highly extensible and able to convey any information that future network engineers might decide to provide. Crucially, this information is represented atomically as a single record, enabling ‘bound’ collections of metadata that only make sense as a whole.
Ready, set, go
The HTTPS record is the first to be ready for broad use. Each HTTPS record provides information about a specific https:// origin, including a domain name and an optional port number. Semantically, it answers the question ‘What should I know about this origin before attempting a connection?’. In reply, the record can say things like:
- The information about this origin is at other.domain.example. Go look there instead.
- This origin has a service endpoint:
- whose IP addresses are in A and AAAA records on target.domain.example
- that also supports HTTP/2 and HTTP/3
- listening on port 54321
- that supports Encrypted ClientHello with the following public key.
A client that sends HTTPS queries gets all of this information before attempting its initial connection. This provides several key benefits for users:
- Performance: Clients can upgrade directly to HTTP/3. This normally will save one RTT on the initial connection and accelerate access to other HTTP/3 performance enhancements.
- Security: The presence of an HTTPS record also tells clients to convert insecure http:// URLs into https:// URLs. This is like HTTP Strict Transport Security (HSTS), but without the need to have visited the origin previously and have the HSTS Policy in cache.
- Privacy: Encrypted ClientHello (ECH) relies on HTTPS records to distribute its public keys. ECH improves the privacy of users’ browsing activity by encrypting the Server Name Indication, which TLS otherwise sends in cleartext.
Service operators also stand to benefit from the use of the HTTPS record, which adds a layer of indirection that may enable more flexible management of HTTP services. Most notably, HTTPS records enable aliasing of apex domains, which is not possible with the CNAME records currently used for aliasing.
By the numbers
Of course, any benefits from these new record types are only possible if clients actually perform queries for them. So do they?
To find out, I analyzed anonymized query logs from Google Public DNS, with the following results:
Figure 1 shows that the HTTPS record type was the third most common query type, representing 3.9% of all incoming queries.
Notably, the sixth most common query type was 65521, a ‘private’ experimental record type used by Chrome known as ‘INTEGRITY’. This experiment, representing 0.4% of queries, was introduced as a pathfinder for the HTTPS record, to detect any errors that might occur when introducing a new record type. Over time, these clients are expected to start sending HTTPS queries instead.
These statistics cover all queries to Google Public DNS, many of which may not be associated with the HTTP protocol or web browsers at all. To focus on web-oriented usage, I also calculated the same statistics for queries whose target was fonts.gstatic.com, a domain that is used almost exclusively in a web context:
Figure 2 shows that HTTPS accounted for 8.9% of queries, with INTEGRITY representing an additional 4.5%. For comparison, AAAA queries represented 14.7% of queries.
As the INTEGRITY experiment winds down, and HTTPS record support ramps up, it seems likely to become the second most popular DNS query type for web domains in the near future.
These numbers suggest that support for HTTPS records is already widespread among web browsers. That’s not surprising, given the implementations by Chrome, Apple, and Firefox, among others. However, it does not tell us any exact proportion. For example, the number of HTTPS queries is likely amplified by the short cache lifetimes applied to NODATA responses. It also doesn’t tell us about the completeness of client implementations, which are still under development.
Hello, operator
The growing support for SVCB and HTTPS records raises new implications and opportunities for network and service operators. Network operators should check if their DNS resolver supports special optimizations for these record types, which can reduce query load and resolution latency. Private network operators should check that their firewalls aren’t blocking these record types, which would reduce security.
For web service operators, growing client support means that it may be time to deploy HTTPS records for your domains. Between HSTS, HTTP/3 upgrade, and apex aliasing, there’s a good chance that HTTPS records can improve the security and performance of your service today.
What’s next?
With the SVCB and HTTPS record types clearing technical review, the IETF is already working on new proposals that make innovative use of these new capabilities.
One notable use of SVCB records is service bindings for DNS, which is entering its final reviews. This specification enables DNS servers to tell the world that they support new encrypted DNS protocols, with security and privacy benefits. The DDR and DNR specifications, also nearly final, build on this, enabling clients to upgrade their connection using this information.
In the IETF’s TLS Working Group, work continues on the ECH specification, which relies on SVCB or HTTPS records to convey public keys. (The SVCB and HTTPS record specification contains extensive discussion of its interaction with ECH, so it won’t be formally published and final until ECH is ready). This group also recently adopted the SNIP proposal, which offers after-the-fact verification of the protocol support advertised in a SVCB or HTTPS record. When connections fail, this might be used to distinguish innocent misconfigurations from network attacks.
As SVCB and HTTPS records become a familiar part of the network engineering toolbox, I hope we’ll see a growing number of creative new ideas for how to use them. Some IETF participants have already imagined ways to use these records to bootstrap Oblivious HTTP configurations and encrypt authoritative DNS. The next great idea could be yours!
Ben Schwartz is a Software Engineer at Jigsaw, a unit within Google, and is a coauthor of the SVCB and HTTPS record specification.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.