Use of HTTPS resource records

Good news, everybody — we have new DNS resource records! Well, not new new, but, you know, newish. You’ve probably heard of them, or even seen them actively in use, even though they moved from Internet draft to formal RFC 9460 adoption literally while I was working on this blog post — the SVCB and HTTPS resource records.

There are a few interesting things to note about these records. They allow you to speed up your time-to-first-packet (by basically stuffing the Alt-Svc HTTP header / ALPN TLS extension into the DNS), let you do redirection on the zone apex without using CNAMEs, allow for simple DNS load distribution and failover, obviate HSTS and the cumbersome preloading process, and enable stronger privacy protections via Encrypted Client Hello (ECH, previously ESNI). Pretty neat, all that.

The record’s main drawback is basically the name. Trying to search the web for information about ‘HTTPS’ is a lot like asking your local library whether they have any books with words.

You can find great explanations of these records elsewhere (for example, here, here, or here), but let’s give a quick example:

$ dig +short https https.test.netmeister.org
1 www.netmeister.org. alpn="h2,http/1.1" ipv4hint=166.84.7.99 ipv6hint=2001:470:30:84:e276:63ff:fe72:3900
$ host https.test.netmeister.org
$

With no A or AAAA records, but the above HTTPS record in place, you should still be able to connect directly to https.test.netmeister.org (Safari gets this right. Firefox only looks up HTTPS records when using DoH, but then also does the right thing. Chrome, as of October 2023 does not support other target names nor use the IP hints in the record.) On the wire, that looks like so (click the image to see the full size):

In Figure 1, you’ll find our HTTPS record lookup in packet #624, followed by an A record lookup in #625, and the HTTPS result in #626. Notice that we then make a TCP connection immediately in packet #627 and begin our TLS handshake in #630, without waiting for the (empty) A record result, which finally arrives in packet #651, showing the use of the ipv4hint from the HTTPS result.

HTTPS records in the wild

Despite just emerging from draft status, we’re already seeing some notable adoption across the industry: Firefox has been making HTTPS lookups (albeit only over DoH) since May 2020, Apple’s iOS and Safari / macOS since September 2020, Chrome has had partial support since December 2020, and just recently enabled ECH by default. Various DNS service providers also offer support for HTTPS and SVCB records.

So with all that, I was curious to see just what the actual adoption of these records is in the wild. I ignored the more generic SVCB record (since it requires knowledge of the scheme and possibly port) and focused only on the HTTPS record, for which I then performed DNS lookups for approximately 227M second-level domain names (for example, example.com). I then repeated the lookups, prefixing each name with www. Finally, I repeated the same exercise for the Tranco Top1M domains.

Logically, the Top1M domains ought to all fall into the comprehensive list of all second-level domain names, but unfortunately, not all second-level domains make available their zones, meaning my list of second-level domains does not include several of the names found in the Top1M list (the missing names generally are those found in ccTLDs that don’t publish their zones for research).

I then analysed the data collected for the different features the record provides. Let’s take a look at how these are used!

Presence of HTTPS records

Not surprisingly, the overall adoption of these records is still low. However, it is not negligible. As of October 2023, I found almost 10 million domains using an HTTPS record for their www service names (~4.4%), and around 9.1 million domains (~ 4.0%) using the record on their bare second-level domain name. For the Top1M domains, there were around 22.5K (25.5%) for the www service names, and almost 24K (25.6%) bare domains using HTTPS records (Figure 2).

SvcPriority

The HTTPS record has the following format:

SvcPriority TargetName SvcParams

The SvcPriority field indicates the mode of the HTTPS record: 0 indicates AliasMode (generally intended to allow aliasing at the zone apex), and any other value indicates ServiceMode.

As such, you might expect a SvcPriority of 0 to be more frequently encountered on the bare domain names, with ServiceMode being indicated for the www. subdomains. However, I found that virtually all existing HTTPS records are in ServiceMode (Table 1):

Table 1 — Nearly all existing HTTPS records are in ServiceMode.

There are a handful of other priorities set, as well as a number of records that have no priority set (erroneous records, likely mistyped), but clearly, ServiceMode is the primary use case right now. I expect this to change as support for HTTPS records increases and organizations begin to adopt them to resolve the ‘no CNAMEs at the apex’ problem. On the other hand, AliasMode currently does not permit SvcParams to be set, so perhaps those will ultimately cause ServiceMode to remain the dominant use.

TargetName

In ServiceMode, the TargetName and SvcParams within each RR associate an alternative endpoint for the service with its connection parameters.

RFC 9460, Sec. 2.4.3

The TargetName field also shows that early adopters of these records do not use them to redirect traffic; virtually all records have the TargetName set to ., meaning the record owner’s name is used:

Table 2 — Nearly all records have the TargetName set to . .

The two other records besides . that stand out here are star.fallback.c10r.facebook.com. and geo-routing.nexuspipe.com..

Facebook / Meta does not currently set HTTPS records on their primary domain names but uses the star.fallback name as a CNAME redirect for mistyped domains, which explains why this shows up a number of times for all of their various typo-squatting and brand-protection names:

$ dig +nocomments +nostats https www.instagra.com

; <<>> DiG 9.18.19 <<>>+nocomments +nostats https www.instagra.com
;; global options: +cmd
;www.instagra.com.              IN      HTTPS
www.instagra.com.       7140    IN      CNAME star.c10r.facebook.com.
star.c10r.facebook.com. 7140    IN      HTTPS   1 . alpn="h2,h3"
star.c10r.facebook.com. 7140    IN      HTTPS   2 star.fallback.c10r.facebook.com. alpn="h2,h3"

The other name (geo-routing.nexuspipe.com.) appears to be used by the ‘NexusPIPE’ cybersecurity company’s DNS services to load-balance or otherwise distribute traffic across different ports, one of the very few uses of the HTTPS record using different priorities and ports for this purpose:

dig +nostat +nocomment https www.fluxteam.net
; <<>> DiG 9.18.19 <<>> +nostat +nocomment https www.fluxteam.net
;; global options: +cmd
;www.fluxteam.net.		IN	HTTPS
www.fluxteam.net.	10	IN	CNAME	geo-routing.nexuspipe.com.
geo-routing.nexuspipe.com. 3472	IN	HTTPS	10 geo-routing.nexuspipe.com. alpn="h2" port=8080
geo-routing.nexuspipe.com. 3472	IN	HTTPS	6 geo-routing.nexuspipe.com. alpn="h2" port=2086
geo-routing.nexuspipe.com. 3472	IN	HTTPS	2 geo-routing.nexuspipe.com. alpn="h2" port=2052
geo-routing.nexuspipe.com. 3472	IN	HTTPS	1 geo-routing.nexuspipe.com. alpn="h2" port=443
geo-routing.nexuspipe.com. 3472	IN	HTTPS	4 geo-routing.nexuspipe.com. alpn="h2" port=2082
geo-routing.nexuspipe.com. 3472	IN	HTTPS	3 geo-routing.nexuspipe.com. alpn="h2" port=2053
geo-routing.nexuspipe.com. 3472	IN	HTTPS	5 geo-routing.nexuspipe.com. alpn="h2" port=2083
geo-routing.nexuspipe.com. 3472	IN	HTTPS	11 geo-routing.nexuspipe.com. alpn="h2" port=8880
geo-routing.nexuspipe.com. 3472	IN	HTTPS	7 geo-routing.nexuspipe.com. alpn="h2" port=2087
geo-routing.nexuspipe.com. 3472	IN	HTTPS	9 geo-routing.nexuspipe.com. alpn="h2" port=2098
geo-routing.nexuspipe.com. 3472	IN	HTTPS	12 geo-routing.nexuspipe.com. alpn="h2" port=8443
geo-routing.nexuspipe.com. 3472	IN	HTTPS	8 geo-routing.nexuspipe.com. alpn="h2" port=2095

SvcParams

RFC 9460 defines the alpn, no-default-alpn, port, ipv4hint and ipv6hint, and mandatory SvcParamKeys. In addition, this Internet draft defines the ech SvcParamKey for ECH.

mandatory and no-default-alpn

These two SvcParamKeys are exceedingly rare. The only domains observed using them are:

• lonios.com. (mandatory=ipv4hint,ipv6hint)
• www.0834-3658888.com. (no-default-alpn=)
• www.014.se. (no-default-alpn=)
• 014.se. (no-default-alpn=)

That’s right: 4 out of ~10 million HTTPS records. That’s it! Well, ok then, let’s look at the others.

alpn

The alpn SvcParamKey is widely used: 99.9% of all HTTPS records observed do set this parameter key; only around 7.6K do not have it set. The breakdown by frequency is:

Table 3 — 99.9% of all HTTPS records observed set the alpn SvcParamKeyset.

This also speaks to the increasing adoption of HTTP/3.

ech

The ech SvcParamKey is virtually unused — right now. When I first ran my data collection, Cloudflare had just announced that they had enabled ECH for all customers, and indeed millions of domains showed ech parameters in their HTTPS records using around 207 unique ECH values. However, soon after (and with decidedly less fanfare or any specific reasons given), Cloudflare disabled ECH again, promising to re-enable it in ‘early 2024’.

As such, as of late October 2023, only three of the Top1M and 16 of all domains in total have ech parameters set:

Table 4 — Only three of the Top1M and 16 of all domains have ech parameters set.

port

The port SvcParamKey is, not surprisingly, hardly used at all. For HTTPS records, port 443 is the default.

Table 5 — only three of the Top1M and 16 of all domains have ech parameters set.

ipv4hint and ipv6hint

IP hints are ubiquitous. Over 99.8% of HTTPS records have ipv4hints set, and over 92.5% have ipv6hints set. There are 12 domains that only use ipv6hints and around 420K that only use ipv4hints.

bare domains	www. subdomains	Top1M bare	Top1M www.
107,131	131,271	91,446	41,623
104.16.16.194	104.16.16.194	141.193.213.10	141.193.213.21
102,582	105,297	79,842	83,093
2606:4700:4400::ac4	2606:4700:4400::ac4	2606:4700:3037::681	2606:4700:3037::681

Now usually when I’ve done this sort of analysis, I’ve also reported on the distribution of IP addresses across Autonomous Systems (ASes), but this time there is hardly any use in doing so, as almost all IPs map only into Cloudflare’s networks:

ASN	Owner / name	Count
13335	CLOUDFLARENET, US	9,592,729
209242	CLOUDFLARESPECTRUM	228,058
273584	LINKED STORE BRASIL […]	24,646
397273	RENDER, US	12,497
12996	DOMENESHOP Oslo, Norway, NO	11,209
16509	AMAZON-02, US	2,199
14061	DIGITALOCEAN-ASN, US	1,828
24940	HETZNER-AS, DE	1,262
	1,805 other	20,319

This suggests that the adoption of the HTTPS record is — at this time, anyway — effectively driven by Cloudflare setting the records by default on all of their domains. Since that includes many small, parked domains or domains with very little traffic, it’s difficult to judge how many organizations currently actually take advantage of the record’s capabilities. I’d guess that most aren’t aware of them at all, and active use is far, far less common.

Summary

As we have seen, despite being a just recently finalized RFC, the use of HTTPS DNS records has already grown beyond just sporadic. If you monitor your organization’s DNS logs, you will find plenty of lookups, as popular browsers have already started to, at least, partially implement support for them.

On the domain side, however, it seems that very few organizations explicitly set them. I’m curious to see how this adoption will spread, and whether we will see regular CNAME records (with time) be replaced by HTTPS records, or if we will primarily see that use at the zone apex.

Generally speaking, I expect CDNs to lead the adoption efforts here, as the benefits are most obvious in their use cases, as is evident from the above findings as well. The adoption of ECH, effectively tied to the HTTPS record, will hopefully also increase as we move forward here. I know I’ll be keeping an eye on that.

Jan Schaumann is a Distinguished Infrastructure Security Architect, and Adjunct Professor of Computer Science, with an interest in information security and the overall health of the Internet, as well as the safety and privacy of its users. You can follow Jan on Mastodon.

This post is adapted from the original at Jan’s Blog.

Rate this article

---

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.