Use of HTTPS resource records

By on 18 Dec 2023

Category: Tech matters

Tags: , , ,

Blog home

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, herehere, or here), but let’s give a quick example:

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

With no A or AAAA records, but the above HTTPS record in place, you should still be able to connect directly to (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):

Figure 1 — HTTPS lookup.
Figure 1 — HTTPS lookup.

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, 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).

Figure 2 — Presence of HTTPS records.
Figure 2 — Presence of HTTPS records.


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.


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 3,159 768 1,272 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 65 . 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 and

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

; <<>> DiG 9.18.19 <<>>+nocomments +nostats https
;; global options: +cmd
;              IN      HTTPS       7140    IN      CNAME 7140    IN      HTTPS   1 . alpn="h2,h3" 7140    IN      HTTPS   2 alpn="h2,h3"

The other name ( 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
; <<>> DiG 9.18.19 <<>> +nostat +nocomment https
;; global options: +cmd
;		IN	HTTPS	10	IN	CNAME 3472	IN	HTTPS	10 alpn="h2" port=8080 3472	IN	HTTPS	6 alpn="h2" port=2086 3472	IN	HTTPS	2 alpn="h2" port=2052 3472	IN	HTTPS	1 alpn="h2" port=443 3472	IN	HTTPS	4 alpn="h2" port=2082 3472	IN	HTTPS	3 alpn="h2" port=2053 3472	IN	HTTPS	5 alpn="h2" port=2083 3472	IN	HTTPS	11 alpn="h2" port=8880 3472	IN	HTTPS	7 alpn="h2" port=2087 3472	IN	HTTPS	9 alpn="h2" port=2098 3472	IN	HTTPS	12 alpn="h2" port=8443 3472	IN	HTTPS	8 alpn="h2" port=2095


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:

  • (mandatory=ipv4hint,ipv6hint)
  • (no-default-alpn=)
  • (no-default-alpn=)
  • (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.


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.


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.


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 domainswww. subdomainsTop1M bareTop1M www.
Table 6 — Over 99.8% of HTTPS records have ipv4hints set, and over 92.5% have ipv6hints set.

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:

ASNOwner / nameCount
13335CLOUDFLARENET, US9,592,729
273584LINKED STORE BRASIL […]24,646
397273RENDER, US12,497
12996DOMENESHOP Oslo, Norway, NO11,209
16509AMAZON-02, US2,199
24940HETZNER-AS, DE1,262
1,805 other20,319
Table 7 — Almost all IPs map into Cloudflare’s networks.

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.


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.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *