Change:
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 URL", 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 "URL" before making other queries. Specifically, the client issues a query for URL ... 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 "URL" ...'. Also, SVCB-DNS defines the term "Binding Authority" specifically to enable unambiguous specification of DDR, but DDR doesn'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 "URL", so it's not at all clear why they can't place AAAA records there as well, and this is all that TargetName means in SVCB. It also doesn't quite address the question of whether TargetName can be "URL", which would be more natural in SVCB. Personally, I don'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 "URL" 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 "URL" 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 "URL" SUDN. I think this should say something like 'for queries to the "URL" zone'. Note that NXDOMAIN means there is nothing underneath (RFC 8020), but NODATA 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 shouldn't retry in a fast loop, but consider a passive attacker who can occasionally become active via some difficult mechanism (e.g. a Kaminsky-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 "URL", not "URL". (Really, it's the SVCB record for "URL", 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 '"URL" and subdomains'? Are we sure this advice applies to all future uses of the "URL" 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

Discussion:
When DNS clients wish to use encrypted DNS protocols such as DNS- over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over- <del> 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. </del> <ins> 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. </ins> This document defines two mechanisms for clients to discover designated resolvers that support these encrypted protocols using DNS

If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a <del> Designated Resolver.  The client can still use other records in the same response if the client can understand all of their mandatory </del> <ins> 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 </ins> 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

4. When a DNS client is configured with an Unencrypted DNS Resolver IP <del> address, it SHOULD query the resolver for SVCB records for the name "resolver.arpa" before making other queries, in order to use </del> <ins> 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 </ins> 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 <del> or used to construct the DoH template MUST be provided. </del> <ins> 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". </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa":

If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" <del> SUDN, to provide a consistent and accurate signal to clients that it </del> <ins> zone, to provide a consistent and accurate signal to clients that it </ins> does not have a Designated Resolver. 4.1.

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 <del> will lead to further failed validations. </del> <ins> 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. </ins> If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the

the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. <del> 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. </del> <ins> 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. </ins> 5.

6.1. <del> 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. </del> <ins> 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. </ins> Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR

that can block these connections can prevent clients from switching to use encrypted DNS. <del> 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. </del> <ins> 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. </ins> While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned