Original text:
When a DNS client is configured with an Unencrypted DNS Resolver IP address, it SHOULD query the resolver for SVCB records for the name <del> "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. </del>  Because this query is for an SUDN, which no entity can claim ownership over, the ServiceMode SVCB response MUST NOT use the "." If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" <del> SUDN. </del>  4.1. A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other <del> Unencrypted DNS Resolver.  Instead, the client SHOULD repeat the </del>  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 The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the <del> default system or application trust anchors. </del>  The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the <del> Unencrypted DNS Resolver. </del>  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 <del> record's Time to Live (TTL). </del>  If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the 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 <del> private or local IP addresses. </del>  5. 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 <del> (bootstrapping), these records SHOULD be available in the public DNS. </del>  For example, if the client already knows about a DoT server "resolver.example.com", it can issue an SVCB query for 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 <del> resolver if there is a conflict. </del>  The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted DNS resolver.  In

Reviewer comments:
NAME 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 don'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!

Revised text:
When a DNS client is configured with an Unencrypted DNS Resolver IP address, it SHOULD query the resolver for SVCB records for the name  <ins> "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. </ins> Because this query is for an SUDN, which no entity can claim ownership over, the ServiceMode SVCB response MUST NOT use the "." If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"  <ins> SUDN, to provide a consistent and accurate signal to clients that it does not have a Designated Resolver. </ins> 4.1. A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other  <ins> Unencrypted DNS Resolver.  Instead, the client needs to repeat the </ins> 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 The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the  <ins> default system or application trust anchors, unless otherwise configured. </ins> The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the  <ins> Unencrypted DNS Resolver, so as to prefer Encrypted DNS whenever possible. </ins> 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  <ins> record's Time to Live (TTL) in order to avoid excessive queries that will lead to further failed validations. </ins> If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the 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  <ins> private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5. 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  <ins> (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. </ins> For example, if the client already knows about a DoT server "resolver.example.com", it can issue an SVCB query for 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  <ins> resolver if there is a conflict, since DNR is considered a more reliable source. </ins> The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted DNS resolver.  In