Why DNS discovery matters for encrypted lookups

Cloudflare's public resolver at 1.1.1.1 handles roughly 600 billion queries each day, but only 11% of that traffic arrives over an encrypted transport. The rest — 89% — is sent as cleartext over UDP and TCP. That gap is not for lack of support: the resolver has offered DNS-over-HTTPS and DNS-over-TLS for years, including HTTP/3 for DoH and Oblivious DoH. The problem is that clients need a way to learn that those encrypted options exist in the first place.

That is the role of Discovery of Designated Resolvers (DDR), an IETF draft specification now experimentally supported by 1.1.1.1. DDR lets a client that is already configured with a resolver's IP address automatically discover the DoH or DoT endpoint for that same resolver, then upgrade the connection without manual setup.

Two questions, one mechanism

Configuring a public resolver involves two distinct decisions. The first is policy-based: which resolver to trust with your queries, and whether its privacy practices and performance suit your needs. The second is technical: what protocol to use when talking to that resolver. Whether a resolver supports DoH is a simple yes-or-no fact.

Within the IETF, the Adaptive DNS Discovery (ADD) Working Group has been chartered to address both. Its mandate includes specifying a discovery mechanism for resolvers that support encryption, and a way to communicate resolver information to clients for selection decisions. The policy side remains subject to ongoing debate. But the technical piece — how to discover encrypted transport parameters for a resolver you already intend to use — has reached a point where Cloudflare could implement and test it with real clients.

Defining the threat model

For discovery to be meaningful, the network between client and resolver must be treated as potentially hostile. In a typical DHCP-based setup, the client receives the recursive resolver's IP address from the network itself, and DHCP is unauthenticated. An active attacker on that path could spoof the resolver address entirely, redirecting DNS traffic to a machine the attacker controls.

DDR does not attempt to solve that problem. There is currently no known way to perform secure DNS discovery when an attacker can influence the client's view of the resolver address. Instead, the discovery mechanism assumes the client already has the correct resolver IP, obtained through some reliable means. It also concedes that a determined attacker can block discovery outright — for instance by dropping the discovery query — so the practical threat model assumes an attacker that can add or modify packets but not drop them.

With those constraints, the problem becomes specific: given a resolver's IP address, how can a client securely learn the parameters for reaching that same resolver over an encrypted transport, in a way that makes it infeasible for an on-path attacker to redirect the client to a different, attacker-controlled resolver?

How DDR works

DDR combines two existing building blocks.

First, certificate-based authentication. The TLS certificate for one.one.one.one, for example, lists multiple IP addresses under its SubjectAlternativeName extension, including 1.1.1.1. That means the certificate proves authority for the IP address as well as the hostname.

Second, SVCB records. These are extensible DNS records that carry key-value information about a service, such as supported application protocols (for instance HTTP/3 via ALPN) and keying material like that used for Encrypted Client Hello.

The discovery process itself runs in three steps:

  1. The client sends a special SVCB query to its existing resolver, asking for that resolver's designations and associated connection parameters.
  2. The client opens a secure connection to the returned designated resolver, say one.one.one.one, and authenticates it against that name.
  3. The client verifies that the designated resolver's certificate also covers the IP address of the resolver it originally queried. If the certificate for one.one.one.one does not include 1.1.1.1 in its SubjectAlternativeName, the validation fails.

If all three steps succeed, the client can treat the encrypted endpoint as the same resolver it originally knew by IP, and switch its traffic to the secure channel. This approach is called "Verified Discovery" in the current DDR draft. An encrypted resolver that does not present a certificate covering the origin resolver's IP will not pass validation, and clients should ignore the advertised upgrade path.

Testing DDR on 1.1.1.1

Cloudflare's experimental deployment can be queried directly. To see the DDR information, send an SVCB query (record type 64) for the reserved name _dns.resolver.arpa to 1.1.1.1:

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

QUESTION SECTION
_dns.resolver.arpa.               IN SVCB 

ANSWER SECTION
_dns.resolver.arpa.                           300    IN SVCB  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}"
_dns.resolver.arpa.                           300    IN SVCB  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"

ADDITIONAL SECTION
one.one.one.one.                              300    IN AAAA  2606:4700:4700::1111
one.one.one.one.                              300    IN AAAA  2606:4700:4700::1001
one.one.one.one.                              300    IN A     1.1.1.1
one.one.one.one.                              300    IN A     1.0.0.1

The response lists the resolver's encryption designations:

_dns.resolver.arpa.                           300    IN SVCB  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}"

That output indicates that the DoH target one.one.one.one is reachable on port 443, supports both HTTP/2 and HTTP/3 (via alpn="h2,h3"), and that the DoH endpoint path is /dns-query{?dns}.

Status and adoption path

The experimental DDR support on 1.1.1.1 is intended to move the standardization process forward and give client implementations something real to test against. Both Microsoft and Apple have announced experimental support for the draft, and Cloudflare is working with them on interoperability.

Looking further out, the hope is to add DDR support to open source DNS client software such as dnscrypt-proxy and BIND's resolver, so that more clients can take advantage of encrypted DNS without depending on manual configuration.