rfc9462v2.txt   rfc9462.txt 
Internet Engineering Task Force (IETF) T. Pauly Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 9462 E. Kinnear Request for Comments: 9462 E. Kinnear
Category: Standards Track Apple Inc. Category: Standards Track Apple Inc.
ISSN: 2070-1721 C. A. Wood ISSN: 2070-1721 C. A. Wood
Cloudflare Cloudflare
P. McManus P. McManus
Fastly Fastly
T. Jensen T. Jensen
Microsoft Microsoft
September 2023 November 2023
Discovery of Designated Resolvers Discovery of Designated Resolvers
Abstract Abstract
This document defines Discovery of Designated Resolvers (DDR), a set This document defines Discovery of Designated Resolvers (DDR), a set
of mechanisms for DNS clients to use DNS records to discover a of mechanisms for DNS clients to use DNS records to discover a
resolver's encrypted DNS configuration. An Encrypted DNS Resolver resolver's encrypted DNS configuration. An Encrypted DNS Resolver
discovered in this manner is referred to as a "Designated Resolver". discovered in this manner is referred to as a "Designated Resolver".
These mechanisms can be used to move from unencrypted DNS to These mechanisms can be used to move from unencrypted DNS to
skipping to change at line 164 skipping to change at line 164
entity. entity.
When a client discovers Designated Resolvers, it learns information When a client discovers Designated Resolvers, it learns information
such as the supported protocols and ports. This information is such as the supported protocols and ports. This information is
provided in ServiceMode SVCB records for DNS servers, although provided in ServiceMode SVCB records for DNS servers, although
AliasMode SVCB records can be used to direct clients to the needed AliasMode SVCB records can be used to direct clients to the needed
ServiceMode SVCB record per [RFC9460]. The formatting of these ServiceMode SVCB record per [RFC9460]. The formatting of these
records, including the DNS-unique parameters such as "dohpath", are records, including the DNS-unique parameters such as "dohpath", are
defined by [RFC9461]. defined by [RFC9461].
The following is an example of an SVCB record describing a DoH server The following is an example of a SVCB record describing a DoH server
discovered by querying for _dns.example.net: discovered by querying for _dns.example.net:
_dns.example.net. 7200 IN SVCB 1 example.net. ( _dns.example.net. 7200 IN SVCB 1 example.net. (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
The following is an example of an SVCB record describing a DoT server The following is an example of a SVCB record describing a DoT server
discovered by querying for _dns.example.net: discovered by querying for _dns.example.net:
_dns.example.net. 7200 IN SVCB 1 dot.example.net ( _dns.example.net. 7200 IN SVCB 1 dot.example.net (
alpn=dot port=8530 ) alpn=dot port=8530 )
The following is an example of an SVCB record describing a DoQ server The following is an example of a SVCB record describing a DoQ server
discovered by querying for _dns.example.net: discovered by querying for _dns.example.net:
_dns.example.net. 7200 IN SVCB 1 doq.example.net ( _dns.example.net. 7200 IN SVCB 1 doq.example.net (
alpn=doq port=8530 ) alpn=doq port=8530 )
If multiple Designated Resolvers are available, using one or more If multiple Designated Resolvers are available, using one or more
encrypted DNS protocols, the resolver deployment can indicate a encrypted DNS protocols, the resolver deployment can indicate a
preference using the priority fields in each SVCB record [RFC9460]. preference using the priority fields in each SVCB record [RFC9460].
If the client encounters a mandatory parameter in an SVCB record it If the client encounters a mandatory parameter in a SVCB record it
does not understand, it MUST NOT use that record to discover a does not understand, it MUST NOT use that record to discover a
Designated Resolver, in accordance with Section 8 of [RFC9460]. The Designated Resolver, in accordance with Section 8 of [RFC9460]. The
client can still use other records in the same response if the client client can still use other records in the same response if the client
can understand all of their mandatory parameters. This allows future can understand all of their mandatory parameters. This allows future
encrypted deployments to simultaneously support protocols even if a encrypted deployments to simultaneously support protocols even if a
given client is not aware of all those protocols. For example, if given client is not aware of all those protocols. For example, if
the Unencrypted DNS Resolver returns three SVCB records -- one for the Unencrypted DNS Resolver returns three SVCB records -- one for
DoH, one for DoT, and one for a yet-to-exist protocol -- a client DoH, one for DoT, and one for a yet-to-exist protocol -- a client
that only supports DoH and DoT should be able to use those records that only supports DoH and DoT should be able to use those records
while safely ignoring the third record. while safely ignoring the third record.
skipping to change at line 230 skipping to change at line 230
record type (64) [RFC9460]. record type (64) [RFC9460].
Responses to the SVCB query for the "resolver.arpa" SUDN describe Responses to the SVCB query for the "resolver.arpa" SUDN describe
Designated Resolvers. To ensure that different Designated Resolver Designated Resolvers. To ensure that different Designated Resolver
configurations can be correctly distinguished and associated with A configurations can be correctly distinguished and associated with A
and AAAA records for the resolver, ServiceMode SVCB responses to and AAAA records for the resolver, ServiceMode SVCB responses to
these queries MUST NOT use the "." or "resolver.arpa" value for the these queries MUST NOT use the "." or "resolver.arpa" value for the
TargetName. Similarly, clients MUST NOT perform A or AAAA queries TargetName. Similarly, clients MUST NOT perform A or AAAA queries
for "resolver.arpa". for "resolver.arpa".
The following is an example of an SVCB record describing a DoH server The following is an example of a SVCB record describing a DoH server
discovered by querying for _dns.resolver.arpa.: discovered by querying for _dns.resolver.arpa.:
_dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net ( _dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
The following is an example of an SVCB record describing a DoT server The following is an example of a SVCB record describing a DoT server
discovered by querying for _dns.resolver.arpa.: discovered by querying for _dns.resolver.arpa.:
_dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net ( _dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net (
alpn=dot port=8530 ) alpn=dot port=8530 )
The following is an example of an SVCB record describing a DoQ server The following is an example of a SVCB record describing a DoQ server
discovered by querying for _dns.resolver.arpa.: discovered by querying for _dns.resolver.arpa.:
_dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net ( _dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net (
alpn=doq port=8530 ) alpn=doq port=8530 )
If the recursive resolver that receives this query has one or more If the recursive resolver that receives this query has one or more
Designated Resolvers, it will return the corresponding SVCB records. Designated Resolvers, it will return the corresponding SVCB records.
When responding to these special queries for "resolver.arpa", the When responding to these special queries for "resolver.arpa", the
recursive resolver SHOULD include the A and AAAA records for the name recursive resolver SHOULD include the A and AAAA records for the name
of the Designated Resolver in the Additional Answers section. This of the Designated Resolver in the Additional Answers section. This
skipping to change at line 419 skipping to change at line 419
Encrypted DNS Resolver itself or to any other resolver. Unlike the Encrypted DNS Resolver itself or to any other resolver. Unlike the
case of bootstrapping from an Unencrypted DNS Resolver (Section 4), case of bootstrapping from an Unencrypted DNS Resolver (Section 4),
these records SHOULD be available in the public DNS if the same these records SHOULD be available in the public DNS if the same
domain name's A or AAAA records are available in the public DNS to domain name's A or AAAA records are available in the public DNS to
allow using any resolver to discover another resolver's Designated allow using any resolver to discover another resolver's Designated
Resolvers. When the name can only be resolved in private namespaces, Resolvers. When the name can only be resolved in private namespaces,
these records SHOULD be available to the same audience as the A and these records SHOULD be available to the same audience as the A and
AAAA records. AAAA records.
For example, if the client already knows about a DoT server For example, if the client already knows about a DoT server
resolver.example.com, it can issue an SVCB query for resolver.example.com, it can issue a SVCB query for
_dns.resolver.example.com to discover if there are other encrypted _dns.resolver.example.com to discover if there are other encrypted
DNS protocols available. In the following example, the SVCB answers DNS protocols available. In the following example, the SVCB answers
indicate that resolver.example.com supports both DoH and DoT and that indicate that resolver.example.com supports both DoH and DoT and that
the DoH server indicates a higher priority than the DoT server. the DoH server indicates a higher priority than the DoT server.
_dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. ( _dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
_dns.resolver.example.com. 7200 IN SVCB 2 resolver.example.com. ( _dns.resolver.example.com. 7200 IN SVCB 2 resolver.example.com. (
alpn=dot ) alpn=dot )
skipping to change at line 460 skipping to change at line 460
server for foo.resolver.example.com. server for foo.resolver.example.com.
6. Deployment Considerations 6. Deployment Considerations
Resolver deployments that support DDR are advised to consider the Resolver deployments that support DDR are advised to consider the
following points. following points.
6.1. Caching Forwarders 6.1. Caching Forwarders
A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or
any subdomains) upstream. This prevents a client from receiving an any subdomains) upstream. This prevents a client from receiving a
SVCB record that will fail to authenticate because the forwarder's IP SVCB record that will fail to authenticate because the forwarder's IP
address is not in the SubjectAltName (SAN) field of the upstream address is not in the SubjectAltName (SAN) field of the upstream
resolver's Designated Resolver's TLS certificate. A DNS forwarder resolver's Designated Resolver's TLS certificate. A DNS forwarder
that already acts as a completely transparent forwarder MAY choose to that already acts as a completely transparent forwarder MAY choose to
forward these queries when the operator expects that this does not forward these queries when the operator expects that this does not
apply, because the operator either knows that the upstream resolver apply, because the operator either knows that the upstream resolver
does have the forwarder's IP address in its TLS certificate's SAN does have the forwarder's IP address in its TLS certificate's SAN
field or expects clients to validate the connection via some future field or expects clients to validate the connection via some future
mechanism. mechanism.
skipping to change at line 520 skipping to change at line 520
directly through DHCP [RFC2132] [RFC8415] and through IPv6 RA options directly through DHCP [RFC2132] [RFC8415] and through IPv6 RA options
[RFC8106]. When such indications are present, clients can suppress [RFC8106]. When such indications are present, clients can suppress
queries for "resolver.arpa" to the unencrypted DNS server indicated queries for "resolver.arpa" to the unencrypted DNS server indicated
by the network over DHCP or RAs, and the DNR indications SHOULD take by the network over DHCP or RAs, and the DNR indications SHOULD take
precedence over those discovered using "resolver.arpa" for the same precedence over those discovered using "resolver.arpa" for the same
resolver if there is a conflict, since DNR is considered a more resolver if there is a conflict, since DNR is considered a more
reliable source. reliable source.
The Designated Resolver information in DNR might not contain a full The Designated Resolver information in DNR might not contain a full
set of SvcParams needed to connect to an Encrypted DNS Resolver. In set of SvcParams needed to connect to an Encrypted DNS Resolver. In
such a case, the client can use an SVCB query using a resolver name, such a case, the client can use a SVCB query using a resolver name,
as described in Section 5, to the Authentication Domain Name (ADN). as described in Section 5, to the Authentication Domain Name (ADN).
7. Security Considerations 7. Security Considerations
Since clients can receive DNS SVCB answers over unencrypted DNS, on- Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB path attackers can prevent successful discovery by dropping SVCB
queries or answers and thus can prevent clients from switching to queries or answers and thus can prevent clients from switching to
using encrypted DNS. Clients should be aware that it might not be using encrypted DNS. Clients should be aware that it might not be
possible to distinguish between resolvers that do not have any possible to distinguish between resolvers that do not have any
Designated Resolver and such an active attack. To limit the impact Designated Resolver and such an active attack. To limit the impact
skipping to change at line 729 skipping to change at line 729
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250, Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022, DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>. <https://www.rfc-editor.org/info/rfc9250>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (DNS SVCB and and Parameter Specification via the DNS (SVCB and HTTPS
HTTPS Resource Records (RRs))", RFC 9460, Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
DOI 10.17487/RFC9460, September 2023, November 2023, <https://www.rfc-editor.org/info/rfc9460>.
<https://www.rfc-editor.org/info/rfc9460>.
[RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers", [RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers",
RFC 9461, DOI 10.17487/RFC9461, September 2023, RFC 9461, DOI 10.17487/RFC9461, November 2023,
<https://www.rfc-editor.org/info/rfc9461>. <https://www.rfc-editor.org/info/rfc9461>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)", the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, September 2023, RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>. <https://www.rfc-editor.org/info/rfc9463>.
9.2. Informative References 9.2. Informative References
[DoH-HINTS] [DoH-HINTS]
Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference
Hints for HTTP", Work in Progress, Internet-Draft, draft- Hints for HTTP", Work in Progress, Internet-Draft, draft-
schinazi-httpbis-doh-preference-hints-02, 13 July 2020, schinazi-httpbis-doh-preference-hints-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-schinazi- <https://datatracker.ietf.org/doc/html/draft-schinazi-
httpbis-doh-preference-hints-02>. httpbis-doh-preference-hints-02>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-16, 6 April 2023, draft-ietf-tls-esni-17, 9 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-16>. esni-17>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011, DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>. <https://www.rfc-editor.org/info/rfc6105>.
 End of changes. 16 change blocks. 
19 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.48.