Draft: draft-ietf-add-ddr

Commentary: I think there are some interesting open questions about the structure of this document , and some details about how recommendations are described , but the technical components are sound . Section 1 : ( DoT ) [ RFC7858 ] , DNS - over - QUIC ( DoQ ) [ RFC9250 ] , or DNS - over - HTTPS ( DoH ) [ RFC8484 ] , they require additional information beyond the IP address of the DNS server , such as the resolver 's hostname , non - standard ports , or URI templates . This is arguably true , but none of these things are relevant in the simplest cases for DoT and DoQ using IP addresses ( Section 4 ) . In those cases , the purpose of this specification is simply to indicate whether the resolver supports DoT or DoQ. That probably bears mentioning here , ahead of the less common metadata like nonstandard ports . I think this is probably a mistake . The fact that there are two very different mechanisms defined here , both known as DDR , has already generated a fair bit of confusion . The second mechanism ( Section 5 ) also seems largely to be repeating the recommendations in draft - ietf - svcb - dns . Given that these two drafts are entering review together , it might make sense to reconsider how material is split between them . Ideally , I think we would adjust the document so that " DDR " means " query " , as that is what everyone seems to think it means . Section 3 : Most of this text seems redundant with draft - ietf - svcb - dns . I understand the desire to avoid making readers read both documents , but some of the text seems especially duplicative , e.g. understand , it MUST NOT use that record to discover a Designated Resolver . This is repeating the normative definition of " mandatory " from draft - ietf - dnsop - svcb - https . If it must be repeated , the repetition could be flagged ( e.g. ' As required by Section 8 of ... ' ) . Section 4 : SHOULD query the resolver for SVCB records for the name " " before making other queries . Specifically , the client issues a query for ... This seems contradictory at a glance . It might be more correct to say ' ... for SVCB records of a service with a scheme of " dns " and an Authority of " " ... ' . Also , SVCB - DNS defines the term " Binding Authority " specifically to enable unambiguous specification of DDR , but DDR does n't use this term . the ServiceMode SVCB response MUST NOT use the " . " value for the TargetName . This rationale is mysterious to me . We 've just told the resolver that they can place SVCB records on " " , so it 's not at all clear why they ca n't place AAAA records there as well , and this is all that TargetName means in SVCB . It also does n't quite address the question of whether TargetName can be " " , which would be more natural in SVCB . Personally , I do n't see the need for this restriction , which I think is a holdover from previous drafts that imposed different semantics on TargetName . Placing AAAA records on " " seems like a fine way for the resolver to tell the client what it thinks its own public ingress IPs are . If the authors think this should be prohibited , perhaps they can clarify the rationale ( e.g. ' To enable reliable identification of the Designated Resolver for debugging and future extensions , TargetName SHOULD NOT indicate a SUDN . ' ) . Relatedly , if " " is not the expected TargetName , this section should probably have a sentence noting that the " speculative A and/or AAAA queries " recommended in Section 5 of draft - ietf - svcb - https are not applicable here . Resolvers , it SHOULD return NODATA for queries to the " " SUDN . I think this should say something like ' for queries to the " " zone ' . Note that NXDOMAIN means there is nothing underneath ( RFC 8020 ) , but  does not . Section 4.1 : This recommendation is obscure . Perhaps an example of a plausible violation would help . Section 4.1.1 : This seems a bit optimistic . For DoQ with resumption " no delay " might be possible , but for DoT a delay of at least 1 RTT is required . Perhaps ' no delay before establishing ' would be more precise . Section 4.2 : Perhaps cite RFC5280 for subjectAltName ? Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record 's Time to Live ( TTL ) . Why ? I agree that the client should n't retry in a fast loop , but consider a passive attacker who can occasionally become active via some difficult mechanism ( e.g. a  - type attack ) . If this attacker can inject a single DDR record with a very long TTL , it can disable DDR passively monitor the DNS queries for a long time . It would be better for the client to retry SVCB resolution more frequently than the ( potentially attacker - controlled ) TTL , to force an active attacker to be more persistent . I think this should say ' TargetName ' . ( This is not " the name of a Designated Resolver " under the standard interpretation of TargetName . ) or ipv4hint or ipv6hint fields of the original SVCB query , the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name . I find this confusing . There are potentially four classes of IP addresses involved here : A. The IP of the unencrypted resolver , provided out of band ( e.g. via DHCP ) B. ipv4hint / ipv6hint C. Additional Section records for TargetName D. Answer Section records for TargetName . This text makes it sound like A - C or B+C have something in common that D does not , but that is not true . In fact , only A is treated specially , and B - D are completely equivalent for DDR . Maybe this text is trying to warn against some implementation mistake ? If so , better to make that explicit . Section 4.3 : I find this confusing , since the SVCB record is at " " , not " " . ( Really , it 's the SVCB record for " " , but " dns : " URIs are controversial at best . ) Section 5 : As discussed earlier , I think it might be better to shrink or eliminate this section . Section 6.1 ' " " and subdomains ' ? Are we sure this advice applies to all future uses of the " " zone ? the SVCB information opportunistically . This seems to contradict Section 4.3 ( Opportunistic Discovery ) , which prohibits the use of the SVCB information in this configuration due to differing IPs of the local and upstream resolvers . Perhaps this should match Section 4.1 's language about " implementation - specific policy " and " future mechanism " , e.g. " ... expects clients to validate the connection via some future mechanism " . Section 7 : Typo : " provides provides " unencrypted DNS until the SVCB record expires , unless verification of the resolver fails . I think the caveat needs to be removed . Otherwise , an attacker on the transport path can cause verification to fail , in order to trigger unencrypted fallback . DNS MUST NOT provide differentiated behavior based on the HTTP path alone ... I think the language on this in draft - ietf - add - svcb - dns is more precise and complete . For example , this description does not cover alternate port numbers , and the use of " separate resolver IP addresses " is unclear ( it means " separate unencrypted resolver IP addresses " ) . The language here should probably match , or be removed and rely on the other draft . 
 LGTM
When DNS clients wish to use encrypted DNS protocols such as DNS-
over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over-
HTTPS (DoH) RFC8484, they require additional information beyond the
IP address of the DNS server, such as the resolver's hostname, non-
standard ports, or URI templates.  However, common configuration
mechanisms only provide the resolver's IP address during
configuration.  Such mechanisms include network provisioning
protocols like DHCP RFC2132 RFC8415 and IPv6 Router Advertisement
(RA) options RFC8106, as well as manual configuration.
When DNS clients wish to use encrypted DNS protocols such as DNS-
over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over-
HTTPS (DoH) RFC8484, they can require additional information beyond
the IP address of the DNS server, such as the resolver's hostname,
alternate IP addresses, non-standard ports, or URI templates.
However, common configuration mechanisms only provide the resolver's
IP address during configuration.  Such mechanisms include network
provisioning protocols like DHCP RFC2132 RFC8415 and IPv6 Router
Advertisement (RA) options RFC8106, as well as manual configuration.
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 DNS 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, in accordance with Section 8 of I-D.ietf-dnsop-
svcb-https.  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 DNS 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.
When a DNS client is configured with an Unencrypted DNS Resolver IP
address, it SHOULD query the resolver for SVCB records for the name
"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.
When a DNS client is configured with an Unencrypted DNS Resolver IP
address, it SHOULD query the resolver for SVCB records of a service
with a scheme of "dns" and an Authority of "resolver.arpa" before
making other queries.  This allows the client to switch to using
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.
Because this query is for an SUDN, which no entity can claim
ownership over, the ServiceMode SVCB response MUST NOT use the "."
value for the TargetName.  Instead, the domain name used for DoT/DoQ
or used to construct the DoH template MUST be provided.
Because this query is for an SUDN, which no entity can claim
ownership over, the ServiceMode SVCB response MUST NOT use the "."
value for the TargetName.  Instead, the domain name used for DoT/DoQ
or used to construct the DoH template MUST be provided.  This ensures
that different designated resolver configurations can be correctly
associated with IP addresses in A and AAAA records.  As such, clients
MUST NOT perform A and AAAA queries for "resolver.arpa".
If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
SUDN, to provide a consistent and accurate signal to clients that it
does not have a Designated Resolver.
If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
zone, to provide a consistent and accurate signal to clients that it
does not have a Designated Resolver.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver if this designation was only
discovered via a "_dns.resolver.arpa." query (if the designation was
advertised directly by the network as described in dnr-interaction,
the server can still be used).  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
record's Time to Live (TTL) in order to avoid excessive queries that
will lead to further failed validations.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver if this designation was only
discovered via a "_dns.resolver.arpa." query (if the designation was
advertised directly by the network as described in dnr-interaction,
the server can still be used).  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
record's Time to Live (TTL) in order to avoid excessive queries that
will lead to further failed validations.  The client MAY issue new
queries if the SVCB record's TTL is excessively long (as determined
by client policy) to minimize the length of time an intermittent
attacker can prevent use of encrypted DNS.
A client MAY use information from the SVCB record for "resolver.arpa"
with this Opportunistic Privacy Profile 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 private or local IP addresses, since resolvers that
use other addresses are able to provision TLS certificates for their
addresses.
A client MAY use information from the SVCB record for
"_dns.resolver.arpa" with this Opportunistic Privacy Profile 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 private or local IP addresses,
since resolvers that use other addresses are able to provision TLS
certificates for their addresses.
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
transparent forwarder MAY choose to forward these queries when the
operator expects that this does not apply, either because the
operator knows that 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 DNS resolver to use the SVCB
information opportunistically.
A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or
any subdomains) 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 transparent forwarder MAY choose to forward these queries
when the operator expects that this does not apply, either because
the operator knows that the upstream resolver does have the
forwarder's IP address in its TLS certificate's SAN field or that the
operator expects clients to validate the connection via some future
mechanism.
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.
Encrypted DNS Resolvers that allow discovery using DNS SVCB answers
over unencrypted DNS MUST NOT provide differentiated behavior based
solely on metadata in the SVCB record, such as the HTTP path or
alternate port number, which are parameters that an attacker could
modify.  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.