Encrypted DNS, Discovered Automatically.

The bootstrap problem

Encrypted DNS needs more than an address to work. To open a DoH, DoT, or DoQ session, a device needs a server name it can check a certificate against, the protocol to speak, a port, and for DoH the URL path. DHCP was designed decades before any of that existed, so all it delivers is an IP address, and the device is left speaking plain port-53 DNS to it by default.

The first workaround was hardcoding: browsers shipped a list of well-known resolver addresses, and when the system resolver matched one, the browser silently switched to that provider's DoH endpoint. It works, but only for the handful of providers on the list, and only inside that browser. Discovery was designed to make the upgrade general: any resolver, any operating system, no list.

DDR: ask the resolver about itself

Discovery of Designated Resolvers takes the resolver the network gave you and asks it one question in plain DNS: an SVCB record for the reserved name _dns.resolver.arpa. The answer is the resolver's own designation: the name of its encrypted service and the parameters needed to reach it. You can watch it happen against this site's resolver:

$ dig @194.180.189.33 _dns.resolver.arpa SVCB +short
1 dnsdoh.art. alpn="h2,h3" port=443 dohpath="/dns-query{?dns}"
1 dnsdoh.art. alpn="doq" port=853

Each line is one designation. The first says: reach this resolver as dnsdoh.art over DoH on port 443, speaking HTTP/2 or HTTP/3, with the query URL built from the dohpath template. The second offers DoQ on port 853. The leading 1 is a priority for when several options are offered; older versions of dig print dohpath by its raw number, key7. From here the device picks a designation it supports, opens the encrypted session, and stops using port 53.

The check that keeps it honest

The discovery query itself travels unencrypted, and anything on the path could answer it, so the reply alone proves nothing. What makes DDR safe is what happens next: the device connects to the designated name and requires a TLS certificate that covers both that name and the original resolver IP it started from. A box in the middle that tried to designate itself would need a certificate for an address it does not own, and the handshake fails.

When the certificate cannot be verified that way, a client can still choose an opportunistic upgrade, encrypting the link without proof of who is on the other end. That defeats passive reading of your lookups but not an active impostor, the same trade described in spoofing and cache poisoning. Verified discovery is the mode that matters.

DNR: the network says it outright

Discovery of Network-designated Resolvers moves the same information one step earlier. Instead of handing out a bare IP and letting the device investigate, the network's DHCP reply or IPv6 router advertisement carries the encrypted resolver's name and connection parameters directly. There is no extra lookup and no unencrypted first step: the device can verify the certificate and start encrypted from its very first query.

DNR is the cleaner design, but it needs network equipment that knows how to send it, so it arrives with new routers and managed networks rather than everywhere at once. DDR asks nothing of the network, which is why it deployed first: Windows 11 and Apple's platforms already perform DDR discovery, and a resolver that publishes the record, like the one above, gets upgraded automatically.

What discovery does not decide

Both mechanisms upgrade the transport to whatever resolver is already in play; they do not pick the resolver. If the network hands you its own resolver and it designates an encrypted version of itself, you are now talking to the same operator over a sealed channel: private from the path, exactly as visible to the operator as before. Choosing who answers your lookups is still your decision, and still the one that matters most, as covered in what a DNS resolver is. Discovery just removes the last excuse for that conversation to happen in plain text.