Draft: draft-ietf-add-ddr

Commentary: This addresses the remaining portions of not address by a prior PR 
 Migrated from original DEER issue : 
 The Special Use Domain Name ( SUDN ) 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 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 will attempt to attach a client to an upstream resource 's equivalent resolver . If that equivalent resolver 's cert does n'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 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 RRset should return NODATA . This would mean that SUDN RRsets are always specific to the IP queried . 
 It may be good to model the advice after  , which defines 
 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 .
If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
SUDN.
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
certficates.  If a deployment uses a different hostname for one
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
not related to the DNS resolver that provided the SVCB answer.
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
certificates.  If a deployment uses a different hostname for one
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
not related to the DNS resolver that provided the SVCB answer.