DDR: The quiet protocol that lets devices find encrypted DNS by themselves

The most interesting protocol news this week is not a new model release or a benchmark. It is a quiet mechanism called Discovery of Designated Resolvers (DDR), and it solves a problem that has haunted DNS since encryption became a priority: a device configured with a bare IP address has no way to learn that its resolver also speaks DoH, DoT, or DoQ. A detailed explainer from the dundns.eu blog walks through the mechanism, and it deserves attention from anyone building AI infrastructure, because DNS is the substrate every distributed training job, every model registry, and every agentic API call silently depends on.

The core trick is elegant. A device that wants to upgrade its DNS connection issues a lookup for _dns.resolver.arpa, a reserved name answered by the resolver it is already using. The reply carries the hostname, port, and protocol of each encrypted endpoint the resolver offers, ranked by preference. A device that speaks DoH, DoT, and DoQ follows that order; a device that speaks only one takes the matching endpoint. Windows 11 and Apple devices already send this question automatically when they join a network, which means the mechanism is live in the wild today, not a draft on a standards-track mailing list.

What makes DDR genuinely new is that it converts an unencrypted connection into a discovery channel without requiring the user to type a single setting. The blog post is precise about the limits: an upgrade starting from plain DNS begins with an unencrypted exchange that 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.

That honesty about the threat model is the most refreshing part of the piece. Too much infrastructure writing gestures at “encryption” as a binary state. DDR’s designers understand that an upgrade path from plain DNS is inherently a negotiation with an adversary who controls the first hop. The protocol does not pretend otherwise.

The per-profile behavior is where the AI angle sharpens. A resolver that keeps per-profile settings can answer with endpoints belonging to the profile that asked, so blocking rules, allow lists, and logging settings configured on that profile apply from the first encrypted query onward. But 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. 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.

That is a privacy design decision with real consequences. It means DDR is most powerful for devices that are already encrypted, and weakest for the devices that need it most: televisions, consoles, and appliances that accept an IP address and nothing else. The blog post is explicit that a browser on DoH or a phone on DoT can send the same question and learn that DoH3 and DoQ are available, and the upgrade inherits the verification of the existing connection. For the unencrypted appliance, the network operator retains a veto.

For AI builders, the implications are concrete. Consider the infrastructure that a frontier lab runs: training clusters that pull model weights from object stores, evaluation harnesses that query public APIs, and agent runtimes that make thousands of DNS lookups per second. Every one of those lookups is a metadata leak. The hostnames alone reveal which model is being fetched, which benchmark is being run, and which vendor’s endpoint an agent is calling. Encrypted DNS does not hide the destination IP, but it does hide the query, and that matters for competitive intelligence and for regulatory compliance alike.

What DDR adds to that picture is the ability to upgrade fleets of devices that previously could not be configured individually. A lab with a thousand headless inference nodes, each provisioned with nothing but an IP address in a DNS settings file, can now inherit encrypted resolution automatically if its resolver supports DDR. The blog post notes that many routers can configure an encrypted resolver on behalf of everything behind them, and DDR covers the devices that neither direct configuration nor router-level configuration reaches. For an AI operation, that is the long tail: the embedded controller in a GPU chassis, the management interface on a switch, the baseboard management controller that phones home.

The economy angle is subtler but real. DNS resolution is a commodity layer, and DDR shifts value toward resolvers that can answer the _dns.resolver.arpa question with rich, per-profile replies. A resolver that offers DoH3 and DoQ endpoints with preference ordering is more attractive to a device that supports both, and the blog post’s comparison of protocols suggests that the endpoint mix is becoming a competitive differentiator. Cloud DNS providers, enterprise resolvers, and privacy-focused public resolvers all have an incentive to publish rich DDR replies, because doing so locks devices into their encrypted endpoints rather than letting them drift to a competitor.

The policy angle is where the tension lives. DDR is opportunistic by design, and that is a feature, not a bug. But the same mechanism that lets a device discover an encrypted endpoint also lets a network operator discover that a device is trying to leave plain DNS. The blog post does not dwell on this, but the implication is unavoidable: a network that can strip DDR replies can also log which devices asked for them, building a list of devices that are attempting to evade inspection. That is a surveillance signal in its own right, and it is one that DDR creates rather than solves.

There is also a deeper architectural lesson for the AI field. The blog post frames DDR as a way to “discover the encrypted endpoints of the resolver it is already using.” That framing is the whole game: the protocol does not introduce a new trust anchor, it upgrades an existing one. The device already trusts the resolver enough to send it plaintext queries. DDR simply asks that same resolver whether it offers a better channel. No new certificate authority, no new bootstrap problem, no new key distribution. The trust model is unchanged, and that is why the mechanism can ship in Windows 11 and Apple devices without a years-long adoption war.

AI systems would benefit from more of that discipline. The field has a habit of introducing new trust anchors to solve problems that an upgraded version of an existing anchor would handle. Federated learning introduces a coordination server; DDR-style thinking would ask whether the existing aggregation point can publish its encrypted capabilities instead. Agent-to-agent authentication introduces a new identity layer; DDR-style thinking would ask whether the existing resolver or registry can answer a discovery query for the agent’s encrypted endpoints. The pattern is general: before adding a new trust anchor, ask whether the one already in place can publish its own upgrade path.

The blog post closes on a practical note, and it is the right one. 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. DDR covers the devices that neither direct configuration nor router-level configuration reaches. That is the honest scope of the mechanism, and it is enough. The long tail of unencrypted devices is exactly where AI infrastructure leaks metadata, and DDR is the first protocol that lets that tail upgrade itself without a human touching a settings screen.

The next time a model registry or an agent runtime ships with a hardcoded DNS IP, the question is no longer whether the resolver can be reached encrypted. It is whether the resolver has published its answer to _dns.resolver.arpa, and whether the device is allowed to ask.