Draft: draft-ietf-add-ddr

Commentary: please check ! 
 I think there are way too many bald SHOULDs in this document . Since SHOULD presents an implementer with a choice , it 's usually a good idea to describe that choice rather than presenting something that looks like " you really should do this , but it 's probably fine if you do n't " and moves on . To wit : An example of one that could use improvement is the first one in Section 4 , as I 've no idea why you would not always do what it says . An example of one that does provide such guidance is the second one in Section 4 , where I understand the consequences of not doing what it says . 
 LGTM !
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.
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, in order to use
Encrypted DNS for all other queries, if possible.  Specifically, the
client issues a query for "_dns.resolver.arpa." with the SVCB
resource record type (64) I-D.ietf-dnsop-svcb-https.
If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
SUDN.
If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
SUDN, to provide a consistent and accurate signal to clients that it
does not have a Designated Resolver.
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.
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 needs to 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.
The client MUST verify the chain of certificates up to a trust
anchor as described in Section 6 of RFC5280.  This SHOULD use the
default system or application trust anchors.
The client MUST verify the chain of certificates up to a trust
anchor as described in Section 6 of RFC5280.  This SHOULD use the
default system or application trust anchors, unless otherwise
configured.
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 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, so as to prefer Encrypted DNS whenever
possible.
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) in order to avoid excessive queries that
will lead to further failed validations.
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.
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, since resolvers that use other
addresses are able to provision TLS certificates for their addresses.
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.
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
if the same domain name's A or AAAA records are available in the
public DNS to allow using any resolver to discover another resolver's
Designated Resolvers.  When the name can only be resolved in private
namespaces, these records SHOULD be available to the same audience as
the A and AAAA records.
Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr)
allows a network to provide designation of resolvers directly through
DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861
options.  When such indications are present, clients can suppress
queries for "resolver.arpa" to the unencrypted DNS server indicated
by the network over DHCP or RAs, and the DNR indications SHOULD take
precedence over those discovered using "resolver.arpa" for the same
resolver if there is a conflict.
Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr)
allows a network to provide designation of resolvers directly through
DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861
options.  When such indications are present, clients can suppress
queries for "resolver.arpa" to the unencrypted DNS server indicated
by the network over DHCP or RAs, and the DNR indications SHOULD take
precedence over those discovered using "resolver.arpa" for the same
resolver if there is a conflict, since DNR is considered a more
reliable source.