Aller au contenu Aller au menu principal Aller au menu secondaire Aller au pied de page

New DNS record types to give more information for client applications

Home > Observatory and resources > Expert papers > New DNS record types to give more information for client applications
01/27/2022

We often read that the DNS “translates domain names into IP addresses”. But this is far from being the whole story. The DNS is in fact a general-purpose service, by no means specific to IP addresses. Apart from these addresses, it also allows to retrieve many other types of data, two of which are currently very close to publishing their technical standards: SVCB and HTTPS.

Recap of DNS record types

The DNS (Domain Name System) allows technical information of various types to be obtained from a domain name such as réussir-en.fr or sw.wikipedia.org. These record types have a digital code (which you can ignore) and a mnemonic consisting of a few letters . For example, the mnemonic ‘MX’ allows the name of the email server for a particular domain name to be obtained. When you write to info@secourspopulaire.fr, the email application will ask the DNS for the MX record of secourspopulaire.fr, which will allow it to then contact the servers indicated.

One of the most common record types is AAAA, which designates the IP addresses identifying devices connected to the Internet, in order to provide the routing of messages to their destination. If you visit the website https://www.ameli.fr/, your browser will ask the DNS for the IP address of www.ameli.fr, and then use this address to connect to the web server.

New record types are regularly created1, and that is the subject of this article.

The problem of the client application

The browser (or any other client application that connects to a server) therefore has the means to find the technical information (the IP address) that it needs. But new demands have appeared more recently. For example, the HTTP protocol now has three versions in current use, versions 1, 2 and 32. None of these three versions is likely to disappear in the short term, as they each have advantages and disadvantages. Within the HTTP protocol there are various mechanisms for informing the client of the versions available on a given server3, but all of them take time since an HTTP connection must first be established, which can be a slow process, particularly if the user has chosen a version that is not managed by the server. Since latency (the time taken for the round-trip to the server) is the main enemy of online performance, it would be good to know which versions can be used before starting to talk  HTTP. And we have the perfect tool for this – the DNS.

The problem is not confined to the three versions of HTTP. Knowing in advance whether the server allows HTTPS (the HTTP version secured by encryption) would be equally useful4.

The new DNS record types presented here also allow the problem of delegation of Internet service to be resolved. If a company called Whatsit has the name whatsit.example but wishes to have its website hosted by an external provider, which prepares the machine under the client name client-56fa3.clients.fournisseur.example, there is currently no really satisfactory solution for carrying out this delegation (it can be done and is done, but using methods that are not very practical5).

The solution

The first new type of DNS record, SVCB (SerViCe Binding) is generic, not specific to a particular service. It allows an indication to be given that a domain name in fact redirects, with a given priority, to another name, with a list of parameters. A client wishing to connect to whatsit.example will therefore recover all the information needed for the connection from a single DNS query (whereas the AAAA type provided only the IP address). For obvious security reasons, it is best that domains using SVCB are protected by DNSSEC.

All seem rather abstract? Let’s look at the second new type of DNS record, HTTPS6. Unlike SVCB, it is specific to a protocol, in this case HTTP. Its form is identical to that of SVCB. So here is a real-life example7, viewed with the Unix dig command8:

% dig mstdn.io HTTPS

;; ANSWER SECTION:

mstdn.io.  282 IN HTTPS 1 . alpn=”h3,h2″

ipv4hint=104.21.77.82,172.67.205.188

ipv6hint=2606:4700:3033::6815:4d52,2606:4700:3037::ac43:cdbc

How to read it? This record tells the HTTP client (for example an Internet browser) that, to connect to mstdn.io (a fediverse server), there is a choice between9 HTTP 2 and HTTP 3 (the alpn parameter), at the IP addresses indicated (to avoid having to make a subsequent AAAA-type query). Other parameters are possible10, for example to indicate the port (an identifier of a particular application on a device) or cryptographic parameters. Furthermore, the mere existence of the HTTPS record indicates that the server accepts the secured HTTPS protocol.

At the time of writing, January 2022, the technical standard describing the types of SVCB and HTTPS records (the RFC, or Request for Comments, a misleading term since it is a definitive document), has not yet been published. The future RFC is still being examined by the IESG.

Deployment

On the Internet, there is no need for an “imprimatur” or licence to print from any particular organisation in order to roll out a service. The Internet is free and open, contrary to the impression given by certain references in the media to one organisation or another as the “Internet regulator,” a function that does not exist. Some successful services, such as BitTorrent and Bitcoin, have thus been deployed without any formal technical standard existing. Indeed, this was also the case of the world-wide web itself, which might never have seen the light of day if it had had to wait for authorisation. While HTTP is formally standardized today, it was not so in its early stages.

And so it is that, before the future RFC has even been approved by the IESG, we are already seeing the deployments of these two new record types on the Internet (in practice, only HTTPS, not SVCB). Here, for example, is what the tcpdump application can observe on one of the authoritative DNS servers for the eu.org domain:

14:32:23.959828 IP X.Y.Z.T.65532 > 172.104.125.43.53: 28264% [1au] Type65? domain1.eu.org. (43)

14:32:24.260731 IP X.Y.Z.T.50162 > 172.104.125.43.53: 34613% [1au] Type65? bfbbf90.domaine2.eu.org. (49)

14:32:25.872131 IP X.Y.Z.T.19924 > 172.104.125.43.53: 45232% [1au] Type65? domain3.eu.org. (52)

We see here three DNS queries from different resolvers, querying the server 172.104.125.43. Since tcpdump does not know the HTTPS type, which is too recent, it posts only its number (65; SVCB is 64). Hundreds per second of such queries can also be seen on the .fr authoritative name servers:

Where do these queries come from? In large part, no doubt, from the iPhone operating system, iOS. Its version 14, released in September 2020, already sends HTTPS queries. The Chrome and Firefox browsers, in their beta versions, already have the possibility of doing the same (although my tests seem to indicate that it is not yet activated).

Note that, at present, an HTTP client application wishing to make use of the HTTPS DNS record type also needs to be able to do without it, since these records are not yet by any means universal. A DNS administrator putting HTTPS records in its domain must also make sure everything works without them, so as not to risk losing its old customers.

Before the advent of SVCB and HTTPS, another type of record had been touted for analogous use – SRV. However it largely failed, at least as regards the Web. The decision not to use it when the Web first started had been a big mistake, and one that was difficult to put right subsequently given the inertia of the Internet: while it is true that no authorisation is needed to deploy a technology, it is conversely also true that having a published technical standard is no guarantee at all of its deployment. We have to rely on the good faith of application publishers, actors who are often little known in what is referred to as “Internet governance.” It is, however, also true that SRV has some limitations that SVCB and HTTPS11 do not.

Conclusion

We can see that the DNS, one of the oldest Internet protocols, continues to evolve. The SVCB and HTTPS record types provide a means of avoiding having to first establish an HTTP connection to find out the characteristics of a server, which should contribute to reducing the latency of online connections.


1 – The complete list can be found in an IANA registry.

2 – IANA uses the QUIC transport layer network protocol.

3 – This is notably the case of the Alt-Svc: mechanism, a field in the heading of the HTTP response.

4 – The HSTS (HTTP Strict Transport Security) system, like the Alt-Svc: mechanisms, requires an initial connection to the HTTP server, thus increasing latency.

5 – This problem is known as “CNAME and other data.”

6 – A poorly chosen name in view of the risk of confusion between the HTTPS protocol and the HTTPS record type.

7 – This record is automatically placed by the Cloudflare hosting system so all the Cloudflare domains have it too, for example cinemasducentre.asso.fr or arts.fr.

8 – It is not the easiest of tools to use and understand but, being recent, the SVCB and HTTPS record types have not yet been integrated into anywhere near all applications.

9 – HTTP 1 does not need to be specified for the time being: it is automatically assumed.

10 – The list will also appear in an IANA registry which at the time of writing, January 2022, has not yet been created.

11 – Since SVC does not allow new parameters such as ALPN (Application Layer Protocol Negotiation) to be added to indicate that HTTP 2 and 3 are accepted.