IBM NS1 Connect

NS1 now supports two new DNS record types: SVCB (“service binding”) and HTTPS.

These record types will soon advance from an IETF draft document to an IETF standards-track RFC. Even though the SVCB and HTTPS record types have not yet finished the standards process, there is widespread support for them among both open source and proprietary DNS libraries and web browsers.

In this article, we’ll cover:

• The challenges that SVCB and HTTPS record types solve, and how the new record types came about

• How SVCB and HTTPS records work, along with the many features they offer

• How you can use SVCB and HTTPS using NS1 Managed DNS

What are the SVCB and HTTPS record types?

DNS already has more than 60 types. What makes the SVCB and HTTPS types especially interesting? Two things stand out:

1. The HTTPS record provides a way to solve the “CNAME-at-apex” problem.

2. Both record types provide information to clients about the best server to use.

Let’s start by looking at how these new record types work, and think a little bit about how SVCB/HTTPS fit into traditional DNS services.

Challenge: CNAME at the Zone Apex

The origins of SVCB/HTTPS lie in a seemingly simple desire… which ends up being really hard to implement in DNS as traditionally structured.

In DNS, you can pick almost any name and have it refer to some other name. You do this by making a CNAME (“canonical name”) record. For example:

www.example.org. 3600 IN CNAME server.example.com.

Using the logic above, any DNS queries (for www.example.org) should get the same answer as server.example.com. This includes any query types, so whether you are looking up the IPv6 addresses (AAAA records), the IPv4 addresses (A records), or anything else, the answer will be that of the CNAME target.

Because the CNAME works for all types, if there is a CNAME for a given name, no other DNS record types are allowed to respond on behalf of at that name.

This system works great, except at the zone apex. The zone apex is the “top” of a zone. So for www.example.com it is example.com. For any zone in DNS, the zone apex has to have at least two records:

1. An SOA (“start of authority”) record

2. At least one NS (“name server”) record

It is very common for other records to appear at the zone apex, such as addresses (AAAA/A) or mail delivery information (MX, for “mail exchange”). Those are optional, while the SOA and NS records are required.

Current solution: ALIAS at the Zone Apex

So why would anyone care about this apparently obscure problem with an Internet protocol? Because it’s very common to want more than one domain to appear as “the same”.

Take for example a company that rebrands a product line. They probably want their old and new brand names to look identical in the DNS; for example when boring-product.com changes to hipname.lol, they want old bookmarks, web searches, and software using their old name to work without having to keep the two domains in sync.

Up to this point, the most common workaround for this situation was an ALIAS record.

With ALIAS records, the authoritative DNS server looks up the answer at the target server, then rewrites the answer so that it appears to be for a different zone. The following diagram shows an example of what might happen during a query served by a server that provides ALIAS record support.

This solution has been in use for some time, and in general, it works pretty well. Over time, however, a few operational problems with ALIAS records have become increasingly problematic.

• The name server with the ALIAS functionality needs to do extra work, making queries slower.

• ALIAS records make debugging problems harder. If the name server with ALIAS functionality returns an error, it could be because of some other server on the Internet.

• Most importantly, ALIAS is not a recognized standard. ALIAS records are implemented in unique ways on every server, which means that they cannot be transferred between different implementations.

Attempted solution: Standardizing ALIAS (ANAME records)

Recognizing the problems with ALIAS records, some IETF participants created a draft for a new type they called ANAME, which was intended to standardize ALIAS records so they would work everywhere.

In addition, the draft ANAME RFC specified DNS recursive resolver behavior which would make it more efficient in some circumstances. That is, an ANAME-aware resolver could perform the lookups and substitution that an authoritative server would do, potentially saving lookups - providing a faster response and using fewer network resources.

While the idea of standardizing ALIAS records was noble, the ANAME RFC process stalled. Clashing priorities between web developers and DNS operators over functionality and security eventually resulted in a revised draft that incorporated a larger spectrum of experts. The result was the SVCB/HTTPS RFC.

How SVCB and HTTPS record types work

To understand how SVCB and HTTPS records work, let's look at the evolution of service discovery in the DNS.

In the mists of prehistory (before RFC 1034 and RFC 1035), there was the MD (“mail domain”) record. It was simple, with the name of a server that would receive mail:

With RFC 1034/1035 (in 1987) came the MX record, which allowed multiple mail servers and also a preference (with lower values being preferred), which allows for rudimentary load balancing and failover:

This approach was generalized in RFC 2052 (in 1996), with the SRV (“server selection”) record. This defined a special name for looking up the service as well as adding a port number for non-standard or undefined ports, as well as a weight to allow unequal load sharing:

Here a user trying to connect to IMAP using TLS would end up at imap-nl1.example.net server 20% of the time and the imap-nl2.example.net server 80% of the time. If both were unreachable then the imap-be1.example.net would be used as a backup.

In principle the SRV record could have been used for WWW traffic any time in the past 20 years or so, but the web community found SRV unfit for that purpose. Luckily they seem enthusiastic about the HTTPS record!

SVCB and HTTPS Record Formats

An SVCB record might look something like this:

The number after “SVCB” is the SvcPriority, mostly functions like priority in MX and SRV records. The exception is if it is 0, in which case SVCB works like a CNAME, with the exception that it can live at a zone apex. This is called AliasMode.

CNAME-at-apex problem solved! However, there is a lot more that SVCB and HTTPS provide.

A more complete example might look something like this:

In this case, we are using the HTTPS record so we can use shorter names. We have a similar AliasMode from example.net to www.example.com. However, www.example.com also has HTTPS records, and these have a SvcPriority that is not 0, so they are in ServiceMode. In the first case, a “.” (dot) is used for the name. That means that the target is the same as the name.

The important difference between the two HTTPS records is the “alpn” value. The first one specifies that the server supports HTTP/1.1 and HTTP/2, and the second one specifies that the server supports HTTP/3 (also known as QUIC). In this way clients can choose the best server available for what protocols they want.

Service Parameters

There are several different service parameters supported. We have already seen one of them, the “alpn”. They all have a similar format, “param=val,val”. They are designed to be extensible, and there is already a draft proposing a new one. (Keen observers will have noticed that SVCB doesn’t include the “weight” value that SRV records have; this may be added in the future via a new service parameter.)

We’ve already seen the “alpn” service parameter. Rather than going through all of the other service parameters, we’ll just touch on a couple that seem especially interesting.

Address Hints

One potential drawback of the SVCB/HTTPS records is that they may add more lookups in order to resolve a name. This could add delays to WWW lookups, which is exactly what these new types are trying to prevent. These extraneous lookups can potentially be avoided with address hints. Address hints use the normal service parameter format, so a record might look like this:

This tells a client that doesn’t already know the AAAA or A address records for the target, example.net in this case, where they can connect. This means they don’t have to do that lookup (or that they can do the lookup in the background and not delay loading the web page).

Encrypted ClientHello

Most web pages are served from servers that support many domains. Likewise, most web pages are served using TLS, which the clients use to authenticate the servers and which encrypts the data on the session. However, the name of the server being connected to is sent without encryption. That means that anyone snooping on the traffic can see which of the domains the client wants - a definite privacy concern.

TLS Encrypted Client Hello is an experimental draft designed to solve this issue. In this technique, the server publishes a key that the client uses to encrypt the request. Since only the server can decrypt a request encrypted with this, privacy is preserved.

One way to get the server key is through the DNS, via the SVCB/HTTPS. Such a record might look like this:

The “ech” service parameter is a base64-encoded version of the public key of the server.

While encrypted client hello is experimental, supporting connections that offer more complete protection against monitoring is an exciting improvement to today’s Internet.

SVCB and HTTPS at NS1

The SVCB and HTTPS types are supported at NS1 today and can be added to zones via any of our supported methods. Usually, this will be either via our web Portal or our REST API, but we also support them via zone transfer.

As with all other DNS records, once added they will be immediately available for query. Note that if you are testing you’ll need to use relatively recent DNS software, otherwise you’ll need to use the generic versions TYPE64 and TYPE65 to query, and the results will be hard to decipher:

A tool updated to a more recent version can use the actual type mnemonic and let you see the contents of the record in an understandable way:

We have ideas about how to make SVCB/HTTPS records work with our ALIAS records and other advanced features like filter chains.

We’d love to hear from you if you have questions or ideas about these new types! Please feel free to contact us.