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):
All bare domains | All www. | Top1M bare domains | Top1M www. | ||||||||
Priority | Count | Priority | Count | Priority | Count | Priority | Count | ||||
1 | 9,902,756 | 1 | 10,069,638 | 1 | 255,940 | 1 | 254,605 | ||||
0 | 4,905 | 0 | 5,173 | 0 | 45 | 2 | 68 | ||||
5 | 78 | 2 | 3,285 | 10 | 10 | 0 | 13 | ||||
2 | 76 | 10 | 132 | 9 | 7 | 9 | 4 | ||||
28 others | 560 | 18 others | 1,010 | 11 others | 68 | 8 others | 28 |
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:
All bare domains | All www. subdomains | ||||
TargetName | Count | TargetName | Count | ||
. | 9,899,763 | . | 9,142,658 | ||
star.fallback.c10r.facebook.com. | 3,159 | geo-routing.nexuspipe.com. | 768 | ||
geo-routing.nexuspipe.com. | 1,272 | hmkb.mydefense.info. | 128 | ||
5,681 others | 6,197 | 4,845 others | 7,504 | ||
Top1M bare domains | Top1M www. subdomains | ||||
TargetName | Count | TargetName | Count | ||
. | 254,600 | . | 255,926 | ||
star.fallback.c10r.facebook.com. | 65 | . | geo-routing.nexuspipe.com. | ||
geo-routing.nexuspipe.com. | 36 | www | 2 | ||
16 others | 17 | 54 others | 56 |
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:
All bare domains | All www. subdomains | Top1M bare domains | Top1M www. subdomains | ||||||||
alpn | Count | alpn | Count | alpn | Count | alpn | Count | ||||
h3, h2 | 8,888,454 | h3, h2 | 8,987,592 | h3, h2 | 217,709 | h3, h2 | 209,767 | ||||
h2 | 252,445 | h2 | 888,675 | h2 | 37,585 | h2 | 44,066 | ||||
h2, h3 | 685 | h2, h3 | 7,669 | h2, h3 | 145 | h2, h3 | 157 | ||||
h3 | 537 | h3 | 1,689 | h3 | 99 | h3 | 98 | ||||
15 others | 65 | 12 others | 60 | 2 others | 2 | 5 others | 9 |
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:
tls-ech.dev. | cloudflareresearch.com. |
17-mai.com. | dramateket.com. |
cloudflare-ech.com. | encryptedsni.com |
cloudflare-esni.com. | epochbelt.com. |
cloudflare-http1.com. | join21.com. |
cloudflare-http2.com. | parachaexperiments.com. |
cloudflare-http3.com. | myechtest.site. |
cloudflare-quic.com. | protocols.team. |
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.
All bare domains | All www. subdomains | Top1M bare domains | Top1M www. subdomains | ||||||||
Port | Count | Port | Count | Port | Count | Port | Count | ||||
443 | 78 | 443 | 23 | 443 | 7 | 443 | 3 | ||||
8443 | 63 | 8443 | 11 | 8443 | 7 | 8443 | 3 | ||||
8880 | 62 | 8880 | 10 | 8880 | 7 | 8880 | 3 | ||||
13 others | 566 | 16 others | 106 | 8 others | 63 | 8 others | 27 |
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.
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.