Draft: draft-ietf-add-ddr

Commentary: Addressing issues and to make the SUDN forwarding a SHOULD NOT unless the operator understands and accepts the implications to authenticated discovery . 
 This is exactly what was intended , so we 're on the same page . 
 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 . 
 Migrated from original DEER issue : 
 The text says This is not true of any reasonable forwarder . RRsets are atomic collections , and can not be mixed from multiple sources . Doing so would entirely break DNSSEC , for example . Unless you know of a forwarder that exhibits this seriously broken behavior , I do n't think it bears mentioning . 
 Addressed with PR 14 
 Typo , but this seems like a reasonable tweak . The description on list was a bit worrying regarding IP address , but this just says do n't forward unless it is deliberate . And by deliberate , I mean that the forwarder knows it will work or that clients might not care . That seems ok .
If a caching forwarder consults multiple resolvers, it may be
possible for it to cache records for the "resolver.arpa" Special Use
Domain Name (SUDN) for multiple resolvers.  This may result in
clients sending queries intended to discover Designated Resolvers for
resolver "foo" and receiving answers for resolvers "foo" and "bar".
A client will successfully reject unintended connections because the
authenticated discovery will fail or the resolver addresses do not
match.  Clients that attempt unauthenticated connections to resolvers
discovered through SVCB queries run the risk of connecting to the
wrong server in this scenario.
To prevent unnecessary traffic from clients to incorrect resolvers,
DNS caching resolvers SHOULD NOT cache results for the
"resolver.arpa" SUDN other than for Designated Resolvers under their
control.
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
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.
Operators who choose to forward queries for "resolver.arpa" upstream
should note that client behavior is never guaranteed and use of DDR
by a resolver does not communicate a requirement for clients to use
the SVCB record when it cannot be authenticated.