Discovering the Discovery of Designated Resolvers

Andrzej Duda and Maciej Korczyński contributed to this work.

DNS encryption is gaining momentum with proposed standards such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) protecting DNS exchanges from external observers. Yet, they introduce non-trivial changes to the original specification through the use of alternative ports, URI paths, or endpoints. In this post, we look at the Discovery of Designated Resolvers (DDR) —  a mechanism that allows clients to obtain encryption configurations of recursive resolvers.

Background

The proposed standard (RFC 9462) defines two modes of operation, both relying on the recently introduced SVCB resource record. The first concerns clients that only know the IP address of a resolver. They either receive its encryption configuration or, if it doesn’t support encryption, a pointer to an alternative endpoint. The second applies when clients are already provisioned with a resolver’s domain name but need to determine its full capabilities. To get a sense of how this works with SVCB records, let’s look at some examples.

The example below shows the IP-based discovery for Cloudflare’s 1.1.1.1,  where we request a special-use domain name _dns.resolver.arpa.  The two SVCB records provide the necessary parameters to establish DoH and DoT connections at one.one.one.one (target name), with the priority field indicating a preference for DoH. This service is supported over both HTTP/2 and HTTP/3 on port 443. The record also contains the URI path and IP address hints. The second SVCB record advertises DoT on port 853.

$ dig @1.1.1.1 _dns.resolver.arpa SVCB +short  

1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?dns}"

2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

The second mode of discovery is for end hosts that are already provisioned with their resolver’s domain but need to determine its full capabilities. As shown in the example below, this time we query the _dns subdomain of one.one.one.one. The DDR specification suggests that “these records SHOULD be available in the public DNS if the same domain name’s A or AAAA records are available in the public DNS to allow using any resolver to discover another resolver’s Designated Resolvers”.

$ dig @1.1.1.1 _dns.one.one.one.one SVCB +short

1 one.one.one.one. alpn="h3,h2" key7="/dns-query{?dns}"

2 one.one.one.one. alpn="dot"

The resolvers referenced in the SVCB entries are called ‘designated’ and may differ from the originally queried IP, hence the name of the proposed standard. The resolvers publishing such records are, in turn, ‘designating’. 

DDR-enabled resolvers

Let’s now find out whether the Discovery of Designated Resolvers is widely deployed in the wild. Having probed 1.3 million open DNS resolvers using the IP-based discovery mechanism, we identified 313k IPv4 and 8.4k IPv6 recursives returning one or more SVCB records with DDR configurations (termed DDR records in the remainder of this blog). We analysed the obtained 676.4k DDR records across two dimensions — encryption protocols and designated public resolvers. All the measurements took place in April 2025.

Encryption protocols

Table 1 shows the number of transport combinations across all the DDR records with their corresponding ratios (‘Count all’ and ‘Ratio all’ columns). DoT and DoH largely prevail in the distribution, collectively accounting for over 99% of the dataset, while the designation of DoQ remains marginal. 

We further narrowed down the analysis to the records with the highest priority only within their corresponding SVCB RRsets (‘Count highest priority’ and ‘Ratio highest priority’). This granularity makes DoT the most preferred encrypted transport, as articulated by the great majority of designating resolvers. Note that while we present the aggregated results for IPv4 and IPv6 resolvers together, we observed the same trends for each IP address family alone, albeit on a different scale.

Protocol(s)	Count all	Ratio all	Count highest priority	Ratio highest priority
dot	325,977	48.22%	281,703	84.99%
h2, h3	302,463	44.74%	42,613	12.86%
h2	43,459	6.43%	4,206	1.27%
doq	2,865	0.42%	1,671	0.50%
h2, h3, http/1.1	1,192	0.18%	1,192	0.36%
doq, dot	57	0.01%	51	0.02%
dot, h2, h3	3	0.00%	3	0.00%

The three encrypted protocols (DoT, DoH, and DoQ) are advertised on as many as 171 different ports, with 853 and 443 being the most common ones. They are well-known system ports for DoT/DoQ for the former and DoH for the latter. Importantly, none of the designated resolvers advertised encrypted services on port 53, explicitly prohibited by the corresponding DoT/DoQ specifications. The use of non-standard ports is allowed as long as a ‘mutual agreement’ is reached (see RFC 7858 and RFC 9250). 

The DoH specification places the definition and distribution of URI templates outside the scope of the protocol. Therefore, designated resolvers advertise this parameter under the key7 or dohpath key. We found 44 unique entries inside the DDR records, /dns-query{?dns} being the most popular. This value, despite not being standardized, is a common example in both DoH and DDR specifications. Other examples include 38 templates from the Control D protective resolvers, which explicitly reflect the particular filtering level (for example, /malware{?dns}, /ads{?dns}, /unfiltered{?dns}) or profile IDs of custom configurations (for example, /<profile_id>{?dns}).

Such cases especially highlight the added value of the DDR mechanism, as clients would not be able to establish the encrypted connection opportunistically on unknown URI paths and non-standard ports.

Designated public resolvers

The target name field (for example, one.one.one.one) contains the domains of designated endpoints, indicating the providers behind these services. We aggregated 1,956 unique targets by registered domains to ensure that we did not overcount the number of entities, for example, dns.opendns.com and doh.opendns.com are both covered under opendns.com.

We saw an apparent dominance of the Google Public DNS with 80.8% of DDR-enabled resolvers designating dns.google or dns64.dns.google to handle encrypted connections. Cloudflare came second at 12.4% with its primary one.one.one.one endpoint. While not under the same registered domain name and, consequently, excluded from this analysis, Cloudflare additionally provides security.cloudflare-dns.com and family.cloudflare-dns.com protective services. OpenDNS, Umbrella, and Quad9 are designated by fewer resolvers, completing the rating of the top five public DNS providers. Overall, these are designated by 97.4% of DDR-enabled resolvers, highlighting the reliance on a handful of big operators.

Conclusions

Having analysed over 321k DDR-enabled open resolvers, we see very little variance in returned configurations. DoT and DoH remain the preferred encryption protocols, with over 85% of resolvers giving DoT the highest priority among their DDR records. Furthermore, the great majority of resolvers designate one of the top five operators, underscoring the degree of centralization present in the DDR ecosystem.

I am a Cybersecurity Researcher at KOR Labs where I analyze all the aspects of the Domain Name System. I am particularly interested in RFC compliance, large-scale Internet measurements, and network security in general. Originally from academia, I enjoy discussing my research with the broader network operators community.

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.