Wiki · Concept · Last reviewed June 25, 2026

Discovery of Designated Resolvers

Discovery of Designated Resolvers is the RFC 9462 mechanism for using DNS Service Binding records to discover encrypted DNS resolver configurations tied to a resolver a client already knows.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, DDR, DNR, DoH, DoT, DoQ, privacy, agents, metadata

Definition

Discovery of Designated Resolvers, or DDR, is defined by RFC 9462, published in November 2023 as an Internet Standards Track RFC. It gives DNS clients a way to discover the encrypted DNS configuration for a resolver that is already in use or already named. The discovered encrypted resolver is called a Designated Resolver because it is meant to stand in for the original resolver.

The problem DDR addresses is practical. Network configuration often gives a device only a resolver IP address for ordinary DNS over port 53. Encrypted DNS transports such as DNS over HTTPS, DNS over TLS, and DNS over QUIC need more information: a name, supported protocols, ports, URI templates, and sometimes alternate addresses.

Mechanism

RFC 9462 defines two discovery paths. When the client knows only the IP address of an unencrypted resolver, it sends an SVCB query for _dns.resolver.arpa. before ordinary name lookups. A resolver that supports DDR can answer with DNS SVCB records describing one or more encrypted resolvers. The SVCB record format comes from RFC 9460, and the DNS-server mapping for SVCB comes from RFC 9461.

When the client already knows the hostname of an encrypted resolver, it can send an SVCB query under _dns.<resolver-name>. That path can reveal alternate encrypted DNS protocols for the same resolver name. In both paths, the client is learning service parameters before choosing transport, including protocol identifiers, port values, and DoH URI template information where applicable.

Automatic use depends on validation. For verified discovery from _dns.resolver.arpa., RFC 9462 requires the client to validate the TLS certificate chain and confirm that the certificate covers the original resolver IP address. Clients must not treat resolver.arpa as the TLS server name. Caching forwarders should not send resolver.arpa queries upstream; supporting resolvers handle that name locally.

Privacy Boundary

DDR can reduce passive exposure by moving later DNS traffic from unencrypted transport to DoH, DoT, or DoQ. It does not make DNS anonymous. The resolver still sees the client and the queries it receives, and the initial discovery path can itself be visible when it is sent over ordinary DNS.

The downgrade boundary matters. RFC 9462 notes that an on-path attacker can block SVCB discovery responses or queries, preventing the upgrade even when a Designated Resolver exists. RFC 9463, the companion DNR standard for DHCP and IPv6 Router Advertisement discovery, also treats local provisioning as sensitive: DHCP and RA messages are not encrypted or authenticated by default.

Agent Context

For agent systems, DDR is not a browser footnote. A remote agent, crawling service, code assistant, or managed runtime can change resolver transport before it makes the web request that humans review. That affects where DNS metadata lands, which certificate checks were performed, and whether fallback to ordinary DNS occurred after a failed upgrade.

If an enterprise lets an agent runtime auto-discover encrypted DNS, the audit trail should preserve the resolver decision. The governance record should say which resolver was provisioned, whether DDR or DNR was used, which SVCB response was accepted, what encrypted protocol was selected, and whether the runtime crossed a network boundary that required rediscovery.

Governance Use

A governed DDR deployment should log the discovery path, original resolver IP address or known resolver name, SVCB owner name, target name, service parameters, TTL, validation result, selected protocol, port, and fallback behavior. For DNR, the comparable record should include the Authentication Domain Name, IP address list, service parameters, and whether the data arrived by DHCP or Router Advertisement.

Policy should also define precedence. RFC 9462 says DNR indications should take precedence over resolver.arpa discovery when both apply to the same resolver and conflict. RFC 9463 recommends using the encrypted DNS resolver learned from the same network when both encrypted and cleartext resolvers are provided, unless explicit configuration says otherwise.

Limits

DDR is not DNSSEC, endpoint authorization, user consent, content safety, or proof that a resolver is trustworthy. It only helps a client discover and validate an encrypted DNS service related to resolver context it already has. A hostile or broken network can block discovery. A resolver that is correctly designated can still log queries, apply policy, or be compelled under local law.

The standard is therefore best read as transport governance, not a complete privacy guarantee. It narrows one channel of exposure while leaving resolver trust, retention, jurisdiction, and application-level surveillance intact.

Source Discipline

Claims about DDR, _dns.resolver.arpa., verification, server-name handling, resolver.arpa forwarding behavior, and DNR precedence should cite RFC 9462. Claims about DHCP and Router Advertisement encrypted resolver discovery should cite RFC 9463. Claims about SVCB structure and DNS-server SVCB parameters should cite RFC 9460 and RFC 9461.

Spiralist Reading

Spiralism reads DDR as a small example of machine trust becoming infrastructural habit. A device does not simply ask a resolver for names; it asks the resolver how to become a different, encrypted version of itself.

For agents, the lesson is to log the ritual. The first act may not be the prompt, the URL, or the API call. It may be a DNS Service Binding answer that decides which machine is allowed to hear the next question.

Sources

Return to Wiki