Draft: draft-ietf-add-ddr

Commentary: Thanks for the painless read ! Just a few trivial comments . Minor : editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is , well , requests to IANA , not interesting and fun trivia about the resources being requested . But , IANA are smart enough to disregard the superflous material . Nits : , The client can still use others records in the same response s / others / other/ , provides provides s / provides//
If the client encounters a mandatory parameter in an SVCB record it
does not understand, it MUST NOT use that record to discover a
Designated Resolver.  The client can still use others records in the
same response if the client can understand all of their mandatory
parameters.  This allows future encrypted deployments to
simultaneously support protocols even if a given client is not aware
of all those protocols.  For example, if the Unencrypted Resolver
returns three SVCB records, one for DoH, one for DoT, and one for a
yet-to-exist protocol, a client which only supports DoH and DoT
should be able to use those records while safely ignoring the third
record.
If the client encounters a mandatory parameter in an SVCB record it
does not understand, it MUST NOT use that record to discover a
Designated Resolver.  The client can still use other records in the
same response if the client can understand all of their mandatory
parameters.  This allows future encrypted deployments to
simultaneously support protocols even if a given client is not aware
of all those protocols.  For example, if the Unencrypted Resolver
returns three SVCB records, one for DoH, one for DoT, and one for a
yet-to-exist protocol, a client which only supports DoH and DoT
should be able to use those records while safely ignoring the third
record.
DoH resolvers that allow discovery using DNS SVCB answers over
unencrypted DNS MUST NOT provide differentiated behavior based on the
HTTP path alone, since an attacker could modify the "dohpath"
parameter.  For example, if a DoH resolver provides provides a
filtering service for one URI path, and a non-filtered service for
another URI path, an attacker could select which of these services is
used by modifying the "dohpath" parameter.  These attacks can be
mitigated by providing separate resolver IP addresses or hostnames.
DoH resolvers that allow discovery using DNS SVCB answers over
unencrypted DNS MUST NOT provide differentiated behavior based on the
HTTP path alone, since an attacker could modify the "dohpath"
parameter.  For example, if a DoH resolver provides a filtering
service for one URI path, and a non-filtered service for another URI
path, an attacker could select which of these services is used by
modifying the "dohpath" parameter.  These attacks can be mitigated by
providing separate resolver IP addresses or hostnames.
This document calls for the addition of "resolver.arpa" to the
Special-Use Domain Names (SUDN) registry established by RFC6761.
This will allow resolvers to respond to queries directed at
themselves rather than a specific domain name.  While this document
uses "resolver.arpa" to return SVCB records indicating designated
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.
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.
This document calls for the addition of "resolver.arpa" to the
Special-Use Domain Names (SUDN) registry established by RFC6761.