Original text:
records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use).  4.1. In order to be considered an authenticated Designated Resolver, the Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS <del> certficates.  If a deployment uses a different hostname for one </del>  protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. 

Reviewer comments:
This addresses the remaining portions of not address by a prior PR
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.

Revised text:
records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use). <ins> If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" SUDN. </ins> 4.1. In order to be considered an authenticated Designated Resolver, the Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS  <ins> certificates.  If a deployment uses a different hostname for one </ins> protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. <ins> The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers.  The intent of the SUDN is to allow clients to communicate with the Unencrypted Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication.  For more context, see the rationale behind "ipv4only.arpa" in RFC8880. </ins>