Draft: draft-ietf-add-ddr

Commentary: Re : section1 , Introduction : Such mechanisms include network provisioning protocols like DHCP [ RFC2132 ] [ RFC8415 ] and IPv6 Router Advertisement ( RA ) options [ RFC8106 ] , as well as manual configuration . Do you know if there is any work being done in the IETF to add more options to DHCP , RA , or manual configuration to allow more complex DHCP server information to be provisioned / setup ? Since longer term that would seem to be an easier / safer solution than needing to use SVCB records to move from unencrypted to encrypted comms . 2 ) I also had a question regarding section 5 : In the following example , the SVCB answers indicate that supports both  and DoT , and that the DoH server indicates a higher priority than the DoT server . 7200 IN SVCB 1 ( alpn = h2 dohpath=/dns - query{?dns } ) 7200 IN SVCB 1 ( alpn = dot ) Is there a bug in the example ( e.g. , second entry should be 2 rather than 1 ) ? Or otherwise it was n't obvious to me why  had higher priority . 
 Would n't " unencrypting resolver " be a more accurate term ? ( Same for " encrypting resolver " . ) Found terminology that should be reviewed for inclusivity ; see for background and more guidance : Term ; alternatives might be , , , , , , , , , , , Use " an " instead of " a " if the following word starts with a vowel sound , e.g. " an article " , " an hour " . Possible typo : you repeated a word .
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  An encrypted resolver discovered in
this manner is referred to as a "Designated Resolver".  This
mechanism can be used to move from unencrypted DNS to encrypted DNS
when only the IP address of a resolver is known.  This mechanism is
designed to be limited to cases where unencrypted resolvers and their
designated resolvers are operated by the same entity or cooperating
entities.  It can also be used to discover support for encrypted DNS
protocols when the name of an encrypted resolver is known.
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  An encrypted DNS resolver discovered in
this manner is referred to as a "Designated Resolver".  This
mechanism can be used to move from unencrypted DNS to encrypted DNS
when only the IP address of a resolver is known.  This mechanism is
designed to be limited to cases where unencrypted DNS resolvers and
their designated resolvers are operated by the same entity or
cooperating entities.  It can also be used to discover support for
encrypted DNS protocols when the name of an encrypted DNS resolver is
known.
When only an IP address of an Unencrypted Resolver is known, the
client queries a special use domain name (SUDN) RFC6761 to
discover DNS SVCB records associated with one or more Encrypted
Resolvers the Unencrypted Resolver has designated for use when
support for DNS encryption is requested (bootstrapping).
When the hostname of an Encrypted Resolver is known, the client
requests details by sending a query for a DNS SVCB record.  This
can be used to discover alternate encrypted DNS protocols
supported by a known server, or to provide details if a resolver
name is provisioned by a network (encrypted).
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
resolver.  "Designated" in this context means that the resolvers are
operated by the same entity or cooperating entities; for example, the
resolvers are accessible on the same IP address, or there is a
certificate that contains the IP address for the original designating
resolver.
When only an IP address of an Unencrypted DNS Resolver is known,
the client queries a special use domain name (SUDN) RFC6761 to
discover DNS SVCB records associated with one or more Encrypted
DNS Resolvers the Unencrypted DNS Resolver has designated for use
when support for DNS encryption is requested (bootstrapping).
When the hostname of an Encrypted DNS Resolver is known, the
client requests details by sending a query for a DNS SVCB record.
This can be used to discover alternate encrypted DNS protocols
supported by a known server, or to provide details if a resolver
name is provisioned by a network (encrypted).
Both of these approaches allow clients to confirm that a discovered
Encrypted DNS Resolver is designated by the originally provisioned
resolver.  "Designated" in this context means that the resolvers are
operated by the same entity or cooperating entities; for example, the
resolvers are accessible on the same IP address, or there is a
certificate that contains the IP address for the original designating
resolver.
A resolver, presumably an Encrypted Resolver, designated by
another resolver for use in its own place.  This designation can
be verified with TLS certificates.
A resolver, presumably an Encrypted DNS Resolver, designated by
another resolver for use in its own place.  This designation can
be verified with TLS certificates.
If the client encounters a mandatory parameter in an SVCB record it
does not understand, it MUST NOT use that record to discover a
Designated Resolver.  The client can still use other records in the
same response if the client can understand all of their mandatory
parameters.  This allows future encrypted deployments to
simultaneously support protocols even if a given client is not aware
of all those protocols.  For example, if the Unencrypted Resolver
returns three SVCB records, one for DoH, one for DoT, and one for a
yet-to-exist protocol, a client which only supports DoH and DoT
should be able to use those records while safely ignoring the third
record.
If the client encounters a mandatory parameter in an SVCB record it
does not understand, it MUST NOT use that record to discover a
Designated Resolver.  The client can still use other records in the
same response if the client can understand all of their mandatory
parameters.  This allows future encrypted deployments to
simultaneously support protocols even if a given client is not aware
of all those protocols.  For example, if the Unencrypted DNS Resolver
returns three SVCB records, one for DoH, one for DoT, and one for a
yet-to-exist protocol, a client which only supports DoH and DoT
should be able to use those records while safely ignoring the third
record.
When a DNS client is configured with an Unencrypted Resolver IP
address, it SHOULD query the resolver for SVCB records for the name
"resolver.arpa" before making other queries.  Specifically, the
client issues a query for "_dns.resolver.arpa" with the SVCB resource
record type (64) I-D.ietf-dnsop-svcb-https.
When a DNS client is configured with an Unencrypted DNS Resolver IP
address, it SHOULD query the resolver for SVCB records for the name
"resolver.arpa" before making other queries.  Specifically, the
client issues a query for "_dns.resolver.arpa" with the SVCB resource
record type (64) I-D.ietf-dnsop-svcb-https.
Designated Resolvers SHOULD be accessible using the IP address
families that are supported by their associated Unencrypted
Resolvers.  If an Unencrypted Resolver is accessible using an IPv4
address, it ought to provide an A record for an IPv4 address of the
Designated Resolver; similarly, if it is accessible using an IPv6
address, it ought to provide a AAAA record for an IPv6 address of the
Designated Resolver.  The Designated Resolver MAY support more
address families than the Unencrypted Resolver, but it SHOULD NOT
support fewer.  If this is not done, clients that only have
connectivity over one address family might not be able to access the
Designated Resolver.
Designated Resolvers SHOULD be accessible using the IP address
families that are supported by their associated Unencrypted DNS
Resolvers.  If an Unencrypted DNS Resolver is accessible using an
IPv4 address, it ought to provide an A record for an IPv4 address of
the Designated Resolver; similarly, if it is accessible using an IPv6
address, it ought to provide a AAAA record for an IPv6 address of the
Designated Resolver.  The Designated Resolver MAY support more
address families than the Unencrypted DNS Resolver, but it SHOULD NOT
support fewer.  If this is not done, clients that only have
connectivity over one address family might not be able to access the
Designated Resolver.
When a client discovers Designated Resolvers from an Unencrypted
Resolver IP address, it can choose to use these Designated Resolvers
either automatically, or based on some other policy, heuristic, or
user choice.
When a client discovers Designated Resolvers from an Unencrypted DNS
Resolver IP address, it can choose to use these Designated Resolvers
either automatically, or based on some other policy, heuristic, or
user choice.
A client MUST NOT re-use a designation discovered using the IP
address of one Unencrypted Resolver in place of any other Unencrypted
Resolver.  Instead, the client SHOULD repeat the discovery process to
discover the Designated Resolver of the other Unencrypted Resolver.
In other words, designations are per-resolver and MUST NOT be used to
configure the client's universal DNS behavior.  This ensures in all
cases that queries are being sent to a party designated by the
resolver originally being used.
If a client is configured with the same Unencrypted Resolver IP
address on multiple different networks, a Designated Resolver that
has been discovered on one network SHOULD NOT be reused on any of the
other networks without repeating the discovery process for each
network.
A client MUST NOT re-use a designation discovered using the IP
address of one Unencrypted DNS Resolver in place of any other
Unencrypted DNS Resolver.  Instead, the client SHOULD repeat the
discovery process to discover the Designated Resolver of the other
Unencrypted DNS Resolver.  In other words, designations are per-
resolver and MUST NOT be used to configure the client's universal DNS
behavior.  This ensures in all cases that queries are being sent to a
party designated by the resolver originally being used.
If a client is configured with the same Unencrypted DNS Resolver IP
address on multiple different networks, a Designated Resolver that
has been discovered on one network SHOULD NOT be reused on any of the
other networks without repeating the discovery process for each
network.
The client MUST verify that the certificate contains the IP
address of the designating Unencrypted Resolver in an iPAddress
entry of the subjectAltName extension as described in
Section 4.2.1.6 of RFC5280.
If these checks pass, the client SHOULD use the discovered Designated
Resolver for any cases in which it would have otherwise used the
Unencrypted Resolver.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver.  Additionally, the client SHOULD
suppress any further queries for Designated Resolvers using this
Unencrypted Resolver for the length of time indicated by the SVCB
record's Time to Live (TTL).
If the Designated Resolver and the Unencrypted Resolver share an IP
address, clients MAY choose to opportunistically use the Designated
Resolver even without this certificate check (opportunistic).
The client MUST verify that the certificate contains the IP
address of the designating Unencrypted DNS Resolver in an
iPAddress entry of the subjectAltName extension as described in
Section 4.2.1.6 of RFC5280.
If these checks pass, the client SHOULD use the discovered Designated
Resolver for any cases in which it would have otherwise used the
Unencrypted DNS Resolver.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver.  Additionally, the client SHOULD
suppress any further queries for Designated Resolvers using this
Unencrypted DNS Resolver for the length of time indicated by the SVCB
record's Time to Live (TTL).
If the Designated Resolver and the Unencrypted DNS Resolver share an
IP address, clients MAY choose to opportunistically use the
Designated Resolver even without this certificate check
(opportunistic).
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on private IP addresses RFC1918, Unique Local
Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291,
whose identity cannot be safely confirmed using TLS certificates
under most conditions.
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted DNS Resolvers on private IP addresses RFC1918, Unique
Local Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927
RFC4291, whose identity cannot be safely confirmed using TLS
certificates under most conditions.
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "resolver.arpa" with this "opportunistic" approach (not
validating the names presented in the SubjectAlternativeName field of
the certificate) as long as the IP address of the Encrypted Resolver
does not differ from the IP address of the Unencrypted Resolver.
Clients SHOULD use this mode only for resolvers using private or
local IP addresses.
A DNS client that already knows the name of an Encrypted Resolver can
use DDR to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted Resolver alongside the resolver IP address, such as
by using Discovery of Network Resolvers (DNR) I-D.ietf-add-dnr.
For these cases, the client simply sends a DNS SVCB query using the
known name of the resolver.  This query can be issued to the named
Encrypted Resolver itself or to any other resolver.  Unlike the case
of bootstrapping from an Unencrypted Resolver (bootstrapping), these
records SHOULD be available in the public DNS.
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "resolver.arpa" with this "opportunistic" approach (not
validating the names presented in the SubjectAlternativeName field of
the certificate) as long as the IP address of the Encrypted DNS
Resolver does not differ from the IP address of the Unencrypted DNS
Resolver.  Clients SHOULD use this mode only for resolvers using
private or local IP addresses.
A DNS client that already knows the name of an Encrypted DNS Resolver
can use DDR to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted DNS Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted DNS Resolver alongside the resolver IP address, such
as by using Discovery of Network Resolvers (DNR) I-D.ietf-add-dnr.
For these cases, the client simply sends a DNS SVCB query using the
known name of the resolver.  This query can be issued to the named
Encrypted DNS Resolver itself or to any other resolver.  Unlike the
case of bootstrapping from an Unencrypted DNS Resolver
(bootstrapping), these records SHOULD be available in the public DNS.
Clients MUST validate that for any Encrypted Resolver discovered
using a known resolver name, the TLS certificate of the resolver
contains the known name in a subjectAltName extension.  In the
example above, this means that both servers need to have certificates
that cover the name "resolver.example.com".  Often, the various
supported encrypted DNS protocols will be specified such that the
SVCB TargetName matches the known name, as is true in the example
above.  However, even when the TargetName is different (for example,
if the DoH server had a TargetName of "doh.example.com"), the clients
still check for the original known resolver name in the certificate.
Clients MUST validate that for any Encrypted DNS Resolver discovered
using a known resolver name, the TLS certificate of the resolver
contains the known name in a subjectAltName extension.  In the
example above, this means that both servers need to have certificates
that cover the name "resolver.example.com".  Often, the various
supported encrypted DNS protocols will be specified such that the
SVCB TargetName matches the known name, as is true in the example
above.  However, even when the TargetName is different (for example,
if the DoH server had a TargetName of "doh.example.com"), the clients
still check for the original known resolver name in the certificate.
As another example, being able to discover a Designated Resolver for
a known Encrypted Resolver is useful when a client has a DoT
configuration for "foo.resolver.example.com" but is on a network that
blocks DoT traffic.  The client can still send a query to any other
accessible resolver (either the local network resolver or an
accessible DoH server) to discover if there is a designated DoH
server for "foo.resolver.example.com".
As another example, being able to discover a Designated Resolver for
a known Encrypted DNS Resolver is useful when a client has a DoT
configuration for "foo.resolver.example.com" but is on a network that
blocks DoT traffic.  The client can still send a query to any other
accessible resolver (either the local network resolver or an
accessible DoH server) to discover if there is a designated DoH
server for "foo.resolver.example.com".
A DNS forwarder SHOULD NOT forward queries for "resolver.arpa"
upstream.  This prevents a client from receiving an SVCB record that
will fail to authenticate because the forwarder's IP address is not
in the upstream resolver's Designated Resolver's TLS certificate SAN
field.  A DNS forwarder which already acts as a completely blind
forwarder MAY choose to forward these queries when the operator
expects that this does not apply, either because the operator knows
that the upstream resolver does have the forwarder's IP address in
its TLS certificate's SAN field or that the operator expects clients
of the unencrypted resolver to use the SVCB information
opportunistically.
A DNS forwarder SHOULD NOT forward queries for "resolver.arpa"
upstream.  This prevents a client from receiving an SVCB record that
will fail to authenticate because the forwarder's IP address is not
in the upstream resolver's Designated Resolver's TLS certificate SAN
field.  A DNS forwarder which already acts as a completely
transparent forwarder MAY choose to forward these queries when the
operator expects that this does not apply, either because the
operator knows that the upstream resolver does have the forwarder's
IP address in its TLS certificate's SAN field or that the operator
expects clients of the unencrypted DNS resolver to use the SVCB
information opportunistically.
The designated resolver information in DNR might not contain a full
set of SvcParams needed to connect to an encrypted resolver.  In such
a case, the client can use an SVCB query using a resolver name, as
described in encrypted, to the authentication-domain-name (ADN).
The designated resolver information in DNR might not contain a full
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,
as described in encrypted, to the authentication-domain-name (ADN).
While the IP address of the Unencrypted Resolver is often provisioned
over insecure mechanisms, it can also be provisioned securely, such
as via manual configuration, a VPN, or on a network with protections
like RA-Guard RFC6105.  An attacker might try to direct Encrypted DNS
traffic to itself by causing the client to think that a discovered
Designated Resolver uses a different IP address from the Unencrypted
Resolver.  Such a Designated Resolver might have a valid certificate,
but be operated by an attacker that is trying to observe or modify
user queries without the knowledge of the client or network.
If the IP address of a Designated Resolver differs from that of an
Unencrypted Resolver, clients applying Verified Discovery (verified)
MUST validate that the IP address of the Unencrypted Resolver is
covered by the SubjectAlternativeName of the Designated Resolver's
TLS certificate.  If that validation fails, the client MUST NOT
automatically use the discovered Designated Resolver.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted Resolver and Designated Resolver have
the same IP address.  Clients which do not follow Opportunistic
Discovery (opportunistic) and instead try to connect without first
checking for a designation run the possible risk of being intercepted
by an attacker hosting an Encrypted DNS Resolver on an IP address of
an Unencrypted DNS Resolver where the attacker has failed to gain
control of the Unencrypted DNS Resolver.
While the IP address of the Unencrypted DNS Resolver is often
provisioned over insecure mechanisms, it can also be provisioned
securely, such as via manual configuration, a VPN, or on a network
with protections like RA-Guard RFC6105.  An attacker might try to
direct Encrypted DNS traffic to itself by causing the client to think
that a discovered Designated Resolver uses a different IP address
from the Unencrypted DNS Resolver.  Such a Designated Resolver might
have a valid certificate, but be operated by an attacker that is
trying to observe or modify user queries without the knowledge of the
client or network.
Unencrypted DNS Resolver, clients applying Verified Discovery
(verified) MUST validate that the IP address of the Unencrypted DNS
Resolver is covered by the SubjectAlternativeName of the Designated
Resolver's TLS certificate.  If that validation fails, the client
MUST NOT automatically use the discovered Designated Resolver.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted DNS Resolver and Designated Resolver
have the same IP address.  Clients which do not follow Opportunistic
Discovery (opportunistic) and instead try to connect without first
checking for a designation run the possible risk of being intercepted
by an attacker hosting an Encrypted DNS Resolver on an IP address of
an Unencrypted DNS Resolver where the attacker has failed to gain
control of the Unencrypted DNS Resolver.