Discovery of Designated Resolvers
Extracted elements (30)
'resolver.arpa' is chosen as a Special-Use Domain Name analogous to 'ipv4only.arpa' (RFC 8880): the client is not interested in an authoritative answer but uses the query to communicate with the locally configured resolver, similar to how 'ipv4only.arpa' enables client-to-middlebox communication.
SVCB records are preferred over alternatives (e.g., TXT overloading, application-layer hints) because they are extensible via typed parameter keys, keep DNS client logic self-contained, and are already required for TLS Encrypted ClientHello (ECH) support, maximizing the privacy benefit when paired with encrypted DNS.
When DNR (RFC 9463) indications via DHCP or IPv6 RAs are present, they SHOULD take precedence over designations discovered via 'resolver.arpa' for the same resolver; clients may suppress resolver.arpa queries when DNR provides the same resolver. If DNR SvcParams are incomplete, a SVCB query to the ADN can supplement them.
A client MAY use SVCB information from _dns.resolver.arpa. with an opportunistic privacy profile only when the Encrypted DNS Resolver's IP address does not differ from the Unencrypted DNS Resolver's IP address; this mode SHOULD be used only for private or local IP addresses.
A client MUST NOT reuse a designation discovered from one Unencrypted DNS Resolver IP address in place of any other Unencrypted DNS Resolver; designations are per-resolver and MUST NOT configure the client's universal DNS behavior.
A Designated Resolver discovered on one network SHOULD NOT be reused on another network using the same Unencrypted DNS Resolver IP address without repeating the discovery process, because the same IP address may map to different servers on different networks.
Clients MUST NOT automatically use a Designated Resolver without some form of validation such as Verified Discovery, Opportunistic Discovery, or a future mechanism; omitting validation allows an attacker to direct traffic to an unrelated Encrypted DNS Resolver.
Clients MUST NOT perform A or AAAA queries for 'resolver.arpa', as the name is a Special-Use Domain Name used solely for SVCB-based resolver discovery.
Clients MUST NOT use 'resolver.arpa' as the server name in the TLS SNI for DoT, DoQ, or DoH connections, nor as the URI host for DoH requests; when discovering via IP address, clients MUST use the original Unencrypted DNS Resolver IP as the DoH URI host.
DNS forwarders SHOULD NOT forward queries for 'resolver.arpa' or its subdomains upstream, to prevent clients receiving SVCB records that will fail authentication due to IP address mismatch in the TLS certificate's SAN.
DNS resolvers supporting DDR by responding to _dns.resolver.arpa. queries MUST treat resolver.arpa as a locally served zone per RFC 6303, responding to non-SVCB queries for _dns.resolver.arpa. and any subdomain queries with NODATA.
Encrypted DNS Resolvers discoverable via SVCB over unencrypted DNS MUST NOT provide differentiated behavior based solely on SVCB metadata (e.g., HTTP path or alternate port), which an attacker could modify to select a different service tier.
For Verified Discovery, the client MUST verify that the Designated Resolver's TLS certificate contains the IP address of the designating Unencrypted DNS Resolver in an iPAddress entry of the subjectAltName extension (RFC 5280 Section 4.2.1.6).
For Verified Discovery, the client MUST verify the Designated Resolver's TLS certificate chain up to a trust anchor per RFC 5280 Section 6, using default system or application trust anchors unless otherwise configured.
If a client encounters a mandatory SVCB parameter it does not understand, it MUST NOT use that record to discover a Designated Resolver; it may still use other records in the response that contain only understood parameters.
If a recursive resolver has no Designated Resolvers, it SHOULD return NODATA for queries to the 'resolver.arpa' zone, providing a consistent and accurate signal to clients.
If Verified Discovery checks fail, the client MUST NOT automatically use the discovered Designated Resolver when it was found via a _dns.resolver.arpa. query, and SHOULD suppress further queries for that Unencrypted DNS Resolver for the SVCB record's TTL.
ServiceMode SVCB responses to _dns.resolver.arpa. queries MUST NOT use '.' or 'resolver.arpa' as the TargetName, so that Designated Resolver configurations can be correctly distinguished and associated with A/AAAA records.
When configured with an Unencrypted DNS Resolver IP address, a client SHOULD query _dns.resolver.arpa. with the SVCB resource record type (64) before making other queries, to allow switching to encrypted DNS for all subsequent queries.
When responding to _dns.resolver.arpa. queries, a recursive resolver SHOULD include A and AAAA records for the Designated Resolver's name in the Additional Answers section to save the client an additional round trip.
When using a known resolver name, clients MUST validate that the Designated Resolver's TLS certificate contains the known name in a subjectAltName extension, regardless of whether the SVCB TargetName differs from the original name.
DDR uses ServiceMode SVCB records with DNS-specific parameters (e.g., 'dohpath' for DoH, 'alpn=dot' for DoT, 'alpn=doq' for DoQ) defined in RFC 9461, queried under the '_dns' service prefix of the resolver's name or the 'resolver.arpa' SUDN.
Designated Resolvers SHOULD be accessible using the same IP address families as the associated Unencrypted DNS Resolver; they MAY support more address families but SHOULD NOT support fewer, to avoid connectivity failures for single-family clients.
Discovery using a known resolver name is triggered by issuing a SVCB query for '_dns.<known-name>', which can be sent to any resolver; the resulting records SHOULD be available in public DNS if the resolver's A/AAAA records are also publicly available.
Opportunistic Discovery allows a client to use a Designated Resolver without certificate name validation when the Designated Resolver shares the same private or local IP address as the Unencrypted DNS Resolver, analogous to the opportunistic privacy profile defined for DoT in RFC 7858 Section 4.1.
To prevent name lookup deadlock, clients MUST NOT use a specific Encrypted DNS Resolver for queries needed to resolve that resolver's own name or to perform certificate revocation checks for it, as described in RFC 8484 Section 10.
IANA has registered 'resolver.arpa' in the 'Special-Use Domain Names' registry (RFC 6761) and added an entry in the 'Transport-Independent Locally-Served DNS Zone Registry' with description 'DNS Resolver Special-Use Domain', referencing this document.
An attacker may attempt to redirect encrypted DNS traffic to a malicious resolver with a valid certificate by causing the client to think the Designated Resolver uses a different IP address; Verified Discovery prevents this by requiring the Unencrypted DNS Resolver's IP to appear in the Designated Resolver's TLS certificate SAN.
Clients using Opportunistic Discovery MUST be limited to cases where the Unencrypted and Designated Resolver share the same IP address (SHOULD be private or local); deviating from this allows attackers to intercept queries via an Encrypted DNS Resolver they control on that IP.
On-path attackers can prevent encrypted DNS discovery by dropping SVCB queries or responses. Clients cannot reliably distinguish between a resolver with no Designated Resolver and an active attack; periodically re-sending SVCB queries limits the impact.