numbers with a blue background
Blog DomainTools Research

The Use Cases and Benefits of SVCB and HTTPS DNS Record Types

Executive Summary

Already used in production, but still not a finalized standard, the SVCB (Service Binding) and HTTPS (Hypertext Transfer Protocol Secure) DNS resource record types offer solutions for issues around service discovery, privacy and performance. This blog post provides further clarity on the use cases and benefits of these new record types.

Introduction: What is Service Binding?

DNS records are analogous to entries in an address book and store information on how to reach a particular contact or, in our case, a system in a computer network. While personal address books are often messy and free form, DNS records have well-defined types of entries. For example, record type “A” contains the internet address for a specific computer (hence, “A” for “address”) and type “CNAME” (or Canonical Name) indicates that a system is known by a different name and so on.

The list of record types continues to evolve and in late 2018 the “service binding” type was proposed to “facilitate the lookup of information needed to make connections for origin resources”. This new record type provides the option to specify alternative endpoints for a name and operates in either of two modes:

  1. AliasMode, where it behaves similarly to a CNAME record
  2. ServiceMode, where it allows the advertisement of a number of different parameters for service discovery.

The proposal also introduces the HTTPS resource record type, a variant of service binding that is specific for HTTPS. The goal of this second record type is to reduce the number of DNS queries for that particular use case, a recurring theme throughout the proposal.

AliasMode, CNAME and Aliasing

The first advantage of adopting SVCB is that it addresses a shortcoming of CNAME records. As mentioned earlier, CNAME creates an alias between two names. Here’s an example record indicating that queries for www.example[.]net should lookup www.example[.]com instead:

www.example[.]net. 3600 IN CNAME www.example[.]com

This aliasing is useful in many situations, but CNAME records cannot be used on what’s called a zone apex or the root domain (the example[.]com portion of the name). This is a historical limitation in how the CNAME type was originally proposed and implemented, and something that can’t be modified at this point. This constraint has led to a few different workarounds, each with its own shortcomings. The SVCB proposal offers a new solution through its AliasMode, allowing us to create a zone apex record and specify a target (or an alternative endpoint) that will further resolve an A, AAAA or SVCB record.

Staying with our previous example, the following SVCB record creates an alias for example[.]net (a zone apex):

example[.]net.	3600 IN SVCB 0	www.example[.]com

The “0” value informs us that this SVCB record is in AliasMode and, in this particular case, the alternative endpoint is the name we’re redirecting to.

ServiceMode, Privacy and Performance

Arguably the main part of the proposal, ServiceMode offers solutions to privacy and performance issues inherent to how service discovery works on the internet.

Front and center is the ability to indicate that a service supports HTTPS directly from the result of a DNS query. Currently, web clients have to first perform a DNS lookup for a service’s internet address and access it “in the clear” with HTTP in the hopes of being redirected to that service’s HTTPS endpoint. Service binding records allow us to specify a parameter called Application-Layer Protocol Negotiation, or ALPN for short, and provide a list of protocols supported by the service. Let’s look at an example:

www.example[.]com 3600 IN SVCB 1	.     alpn=h2

This SVCB record informs us that www.example[.]com supports the HTTP/2 protocol. Notice that we’re not specifying an alternate endpoint in this case, the period before the ALPN parameter tells us that it applies to the record owner. It is also possible to specify a different target, for example:

www.example[.]com.	3600 IN HTTPS 1	svc.example[.]com.	alpn=h2

Both inform clients of the support for HTTP/2. The second example redirects queries to svc.example[.]com. This allows us to connect directly to an HTTPS endpoint, reducing the need for multiple requests and improving privacy by reducing the number of unencrypted messages.

The same mechanism can be used to indicate support for HTTP/3, which offers some very interesting performance benefits over previous versions. The proposal includes an optional “port” parameter that can be used to indicate on which network port the specified services can be reached.

The Encrypted Client Hello (or ECH) parameter, another part of the new specification, helps to close an important privacy gap in how a secure connection is established. With Transport Layer Security (TLS), the client and server must exchange a few pieces of vital information as part of a handshake process, including the service that the user’s trying to connect to. Unfortunately, even the latest TLS standard doesn’t provide for complete encryption and some parts of that conversation can still be intercepted.

Although ECH was already in use before service binding was proposed, it required a separate TXT record. By bundling it with additional parameters in the service binding registry, the cost of additional queries and their processing is reduced. In our previous example, we would have:

www.example[.]com.	3600 IN HTTPS 1	svc.example[.]com     alpn=h2 ech=abcdefgh

In addition to ALPN and ECH, SVCB proposes the ipv4hint and ipv6hint parameters. Similarly to what was done with ECH, their intended purpose seems to be the bundling of all information required to speed up access in a single DNS record and avoid multiple queries. The addresses provided here may be used to reach the given service and if A or AAAA records for the target are locally available, the client should ignore these hints.

All of the parameters we covered in this post are part of a Service Binding Parameter Registry, which also contain the mandatory and a no-default-alpn parameters, a range for private use and allow for arbitrary key value pairs using the keyNNNNN=value format. Unfortunately, the proposal doesn’t offer any additional information on how the private range is or will be used.

Conclusion

The service binding proposal offers a method to streamline the retrieval of DNS data by condensing all the necessary information into a single record. It also narrows the gap through which privacy can be infringed upon during service discovery. The additional flexibility of redirecting requests through its alternative endpoints is a welcomed one and should be valuable for multi-hosting scenarios.

Multiple DNS providers and web clients have already deployed support for SVCB and HTTPS records, from Google and Cloudflare to iOS, Chrome and Firefox. This push for adoption before the proposal reaches the standard phase isn’t uncommon in the networking world, and with big names behind it, SVCB and HTTPS are quickly becoming a de facto standard.

Author: Rafael Vanoni