Discovery of Designated Resolvers needs validation before automation

DNS clients often know only the IP address of a resolver. Discovery of Designated Resolvers, or DDR, lets a client discover that resolver's encrypted DNS configuration through DNS records. The mechanism can make encrypted DNS deployment easier. It also creates a trust decision that a client must make before it switches.

RFC 9462 defines DDR around SVCB and HTTPS resource records for a special resolver domain. The discovery process is designed for cases where the unencrypted resolver and the designated resolver are operated by the same entity or cooperating entities. It is not a general-purpose trust signal for any DNS server that happens to answer the query.

Verified discovery and opportunistic discovery are different

The RFC describes two automatic paths. Verified Discovery uses a TLS certificate to validate the designated resolver's identity. Opportunistic Discovery is limited to a resolver on a private or local address, where the unencrypted resolver and the designated resolver have the same IP address.

Clients must not automatically use a designated resolver without some validation. The RFC explicitly warns that a client should not connect merely because it received an SVCB answer over unencrypted DNS. An on-path attacker could modify or replace the record, and a resolver hosted at the expected IP address might not be the intended encrypted service.

The security value comes from connecting the DNS discovery result to a TLS identity check and a policy decision. The record is a hint. The certificate, the resolver identity, and the client's configuration determine whether the hint is acceptable.

Do not confuse DDR with network-designated resolvers

RFC 9463 defines DHCP and Router Advertisement options for Discovery of Network-designated Resolvers, or DNR. DNR can carry a resolver name and configuration directly through local network provisioning. DDR uses ordinary DNS discovery, including the possibility of unencrypted DNS.

A client policy may treat local network provisioning differently from a public resolver's SVCB record. The two mechanisms have different assumptions about who controls the network and how the information is protected. Do not collapse them into one "encrypted DNS is enabled" flag.

DNS forwarders also need a policy. RFC 9462 advises that a forwarder should not forward queries for resolver.arpa upstream, because a client could receive a record intended for another resolver and then fail certificate validation. A transparent forwarder may have a reason to behave differently, but the decision should be explicit and tested.

Build a validation path

Inventory the resolvers configured on managed clients, including those supplied by DHCP, VPN, and operating system policy. Record whether the client uses DoH, DoT, DoQ, or unencrypted DNS, and whether the name is pinned by policy.

For DDR, test the resolver's SVCB answer and the designated resolver's TLS certificate together. Confirm that the certificate matches the resolver identity and that the client does not fall back to an unverified resolver when validation fails. Verify the client behavior on the actual operating system and browser or stub resolver that will use the policy.

Log the discovery result, validation result, selected protocol, and resolver identity. Do not log query contents. A resolver that changes from a verified path to opportunistic discovery should produce an alert if the client's policy requires verified encryption.

Control automatic switching

Give the client a deterministic policy. It should know which resolver names are allowed, whether automatic discovery is permitted, and what happens when the record is absent or invalid. A policy that says "use encrypted DNS when available" without specifying trusted resolver identities is too vague for an enterprise.

Test failure modes: an SVCB response with an unexpected name, a certificate mismatch, a resolver that stops answering, and a network that blocks the designated endpoint. The client should fail closed or use a previously approved resolver. It should not silently downgrade to plaintext or select an arbitrary resolver from a search response.

The operational lesson

DDR can reduce the manual work of moving from a resolver IP address to an encrypted resolver configuration. Its benefit depends on a client that validates the discovered identity and on an operator that documents the trust relationship.

The mechanism is not a substitute for resolver inventory or certificate management. It is a discovery layer that should make those controls easier to test. A client that accepts an unvalidated SVCB answer has replaced a static resolver setting with a dynamic trust decision that may be less predictable.