How a device finds encrypted DNS by itself

DDR lets a device discover the encrypted endpoints of the resolver it is already using.

A device is normally configured with a single IP address for its DNS resolver. That address reaches the resolver over plain, unencrypted DNS, which is all a bare IP address can describe. Encrypted DNS requires more: a hostname to check the certificate against, a port, and a protocol. None of that fits in the settings box, and none of it can be worked out from the address already sitting there.

DDR, short for Discovery of Designated Resolvers, gives a resolver a way to publish those details to any device already talking to it.

How the question works

The question is a lookup for _dns.resolver.arpa, a name reserved for this purpose and answered by whichever resolver the device is currently using. It amounts to asking whether an encrypted version exists, and where it can be reached.

A resolver that has one replies with the hostname, port, and protocol of each encrypted endpoint it offers, and marks each with a preference. A device that speaks several protocols follows that preference order; a device that speaks one takes the endpoint matching it. The endpoints on offer are usually some mix of DoH, DoT, and DoQ, which an earlier post compares. Where a resolver offers no encrypted endpoints, the reply says so explicitly.

The device then opens a connection to whichever endpoint it picked, and every query from that point on is encrypted. Windows 11 and Apple devices send the question automatically when they join a network.

What comes back

The contents of that reply depend on how the resolver is built. A resolver that applies the same filtering to everybody publishes one set of endpoints, and every device receives an identical answer.

A resolver that keeps per-profile settings can answer with endpoints belonging to the profile that asked, so the blocking rules, allow lists, and logging settings configured on that profile apply from the first encrypted query onward.

Answering that way depends on the resolver identifying the profile behind the question. A query arriving over an existing encrypted connection identifies itself, because the profile is part of how that connection was established in the first place. A query arriving over plain DNS carries no such marker, leaving its source address as the only available signal, so that address has to be linked to the profile in advance. Queries from an unlinked address get a reply listing no endpoints.

The reply also includes the IP addresses of the endpoints it names, which saves the device a second lookup to resolve the hostname it has just been handed. That lookup would otherwise travel over the same unencrypted connection the device is trying to leave.

Where it helps most

A device that is already encrypted. A browser on DoH or a phone on DoT can send the same question and learn that DoH3 and DoQ are available. The exchange happens inside a connection that is already encrypted and certificate-verified, so the upgrade inherits that verification. A device identified by name on its existing connection keeps that name across the switch, since the name travels with the connection.

A device limited to plain DNS. Televisions, consoles, and appliances that accept an IP address and nothing else can be moved onto an encrypted connection with no configuration of their own.

What it does not do

An upgrade starting from plain DNS begins with an unencrypted exchange, which the network can read and alter. A network operator intent on keeping DNS unencrypted can strip or rewrite the reply, and the device has no way to detect it. Clients treat this route as opportunistic for that reason, taking the upgrade when it succeeds and continuing on plain DNS when it fails. Stricter clients go further and require the designated endpoint’s certificate to name the IP address they started from, declining the upgrade when it does not.

Configuring an encrypted resolver directly on a device remains the stronger option wherever the settings allow it, since the connection is verified from the first query and travels with a laptop or phone onto any network. Many routers can configure one on behalf of everything behind them. DDR covers the devices that neither route reaches.