jiebi/CodeConvo huggingface dataset:
Change:
Addressing
We should be explicit about AliasMode DDR records and give an example of where they are used. We should also mention the additional client complexity here, and we may wish to require that the unencrypted resolver include both the AliasMode and ServiceMode records in its response (with the latter in the additional section). A common use-case here will be if a network operator is using a managed service to provide a designated resolver service. In these cases it may be preferable to have URL be an AliasMode record to a ServiceMode record managed by the manage service operator.
One small nit, to avoid quasi normative language (may/MAY -> can).

Discussion:
When a client discovers Designated Resolvers, it learns information such as the supported protocols and ports.  This information is <del> provided in Service Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </del> <ins> provided in ServiceMode Service Binding (SVCB) records for DNS Servers, although AliasMode SVCB records can be used to direct clients to the needed ServiceMode SVCB record per I-D.ietf-dnsop- svcb-https.  The formatting of these records, including the DNS- unique parameters such as "dohpath", are defined by I-D.ietf-add- svcb-dns. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net":

record type (64) I-D.ietf-dnsop-svcb-https. Because this query is for an SUDN, which no entity can claim <del> ownership over, the SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. </del> <ins> ownership over, the ServiceMode SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa":
Change:
From WGLC, Med wrote:
Also, a suggestion to say: use DDR to discover details about all supported encrypted DNS protocols. This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name for an Encrypted Resolver alongside the resolver IP address.

Discussion:
be configured to present the appropriate TLS certificate when no SNI is present for both DoT and DoH. <ins> 6.4. Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr) allows a network to provide designation of resolvers directly through DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861 options.  When such indications are present, clients can suppress queries for "resolver.arpa" to the unencrypted DNS server indicated by the network over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using "resolver.arpa" for the same resolver if there is a conflict. The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted resolver.  In such a case, the client can use an SVCB query using a resolver name, as described in encrypted, to the authentication-domain-name (ADN). </ins> 7. Since clients can receive DNS SVCB answers over unencrypted DNS, on-
Change:
Addressing
NAME I've bravely stolen some text to meet the additional IANA request.
Resolvers will normally return NXDOMAIN for queries that don't exist, and caches are permitted to treat this as an indication that no records of any type exist at the zone (RFC 8020). That means that it isn't enough for resolvers to synthesize a SVCB response for URL they also have to synthesize a NOERROR response for any other QTYPE on that name. The draft should probably mention that. Credit to NAME for noticing this.
NAME agreed that we could note this, but it's also expected that a client wouldn't be sending out queries for other types on URL, right? In practice, I'm not sure how this would happen.
Yes, but if a cache is shared by multiple clients (be they distinct devices on a network or even distinct apps on a device), a single client could issue a query that causes the shared cache to remember the NXDOMAIN answer. That's a problem whether the source of the query is malicious or just weird.
Fair, so this could be accidental or malicious fallout, not a normal occurrence.
I'd suggest that there should also be a reference to RFC 6303 section 3 - should be considered a "locally resolved domain".
Closed with

Discussion:
6.4. <ins> DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under resolver.arpa with NODATA. 6.5. </ins> Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr) allows a network to provide designation of resolvers directly through DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861

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. <ins> IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. </ins>
Change:
Yeah, we want the trailing dot in official DNS records, but I think it's unnecessary elsewhere (IMO).
I assume the trailing dot is unnecessary for domain names in the non-example text because it can be more human friendly and not exact format? Assuming yes to that, LGTM

Discussion:
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 <del> 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. </del> <ins> 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 resolver to use the SVCB information opportunistically. </ins> Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR
Change:
There is no need to use a DNS URI for this. You are only using the name. And you don't cite RFC 4501. It is also incorrect, because you are treating "URL" as the authority, rather than the qname. What you really want is "URL;type=64" or something like that. But the words you have are adequately clear.

Discussion:
4. When a DNS client is configured with an Unencrypted Resolver IP <del> address, it SHOULD query the resolver for SVCB records for "dns://resolver.arpa" before making other queries.  Specifically, the </del> <ins> address, it SHOULD query the resolver for SVCB records for the name "resolver.arpa" before making other queries.  Specifically, the </ins> client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https.

If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. <del> When responding to these special queries for "dns://resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section. This will allow the DNS client to make queries over an encrypted </del> <ins> When responding to these special queries for "resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section.  This will allow the DNS client to make queries over an encrypted </ins> connection without waiting to resolve the Encrypted Resolver name per I-D.ietf-dnsop-svcb-https.  If no A/AAAA records or SVCB IP address hints are included, clients will be forced to delay use of the

a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB <del> record for "dns://resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </del> <ins> record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver. Clients SHOULD use this mode only for resolvers using private or local IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.
Change:
But all bets are off with trust anchors outside of the WebPKI. (Plus a small tweak to the next paragraph.)

Discussion:
configuration over unencrypted DNS is not possible.  This includes Unencrypted Resolvers on private IP addresses RFC1918, Unique Local Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291, <del> whose identity cannot be confirmed using TLS certificates. </del> <ins> whose identity cannot be confirmed using TLS certificates under most conditions. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver
Change:
That's it apparently. No mention of RFC 6125(bis). On that basis, a self-signed certificate suffices. This is something that recently came up on the mailing list and apparently current deployments are validating based on WebPKI trust anchors in addition to checking for the iPAddress subjectAltName. So it's not as bad as this allows. Maybe that should be written down. The same problematic text is found in Section 4.2 and Section 5.
NAME do you have a suggestion about the right way to explain the trust anchor use here? Any text we can model after?
s/MUST contain/MUST prove authority over/ ?
I'm not looking to aggressively economize here. I was wrong about 6125. A reference to URL for the IP reference identity might be needed to cover the SAN validation piece. RFC 6125bis doesn't include the IP-ID piece, which is something I'm going to take up with the UTA WG... But it is RFC 5280 that you really want here. describes how you take a certificate and determine if you trust what it says. Start there, then talk about what the certificate needs to say (IP SAN) in order for it to be accepted. (BTW, RFC 9110 doesn't cite Section 6 of RFC 5280. It should, and it is probably my fault that it doesn't. Section 1.2 of RFC 6125bis says "In order to ensure proper authentication, applications need to verify the entire certification path as per ]" but this is a bit weak.) This is about a paragraph all up, which isn't too much to ask.
NAME take a look at the proposed text
LGTM

Discussion:
handshake. In order to be considered a verified Designated Resolver, the TLS <del> certificate presented by the Designated Resolver MUST contain the IP address of the designating Unencrypted Resolver in a subjectAltName extension.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the </del> <ins> certificate presented by the Designated Resolver needs to pass the following checks made by the client: The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the default system or application trust anchors. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver. If these checks fail, the client MUST NOT automatically use the </ins> discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB
Change:
NAME please review!!
What does this mean? I'm struggling to work out what this might mean for someone operating a DoH server. Does this mean that rewriting "/doh{?dns}" to "/~attacker/abcdef{dns}URL" is considered something that the DoH resolver needs to identify and recover from? Or, is this more narrow in that a DoH server cannot offer two different services on a referred endpoint with different treatment policies? In the former case, the attacker can deny service by modifying the "dohpath". In the latter case, the attacker gets to choose which of the two services is used. I think that you want to lump the former under the general DoS risk. But the latter implies something very specific in terms of action on the part of the resolver operator. They cannot offer more than one DoH service on the same IP address (where DDR doesn't give them any virtual hosting capabilities via SNI) or hostname (where it does). You might need to be a lot clearer about that.
This is about the latter case — if the resolver offers two very different services on different paths, the attacker would get to choose which service is used. That doesn't mean you can't offer different services on the same resolver IP address, but something else would need to be different other than the path — like, for DDR clients, they'll be using the IP address, but some client that was configured with a specific service might use a specific hostname too.
This is from this: URL
See also: URL
NAME please see
Thanks NAME this is an improvement.LGTM

Discussion:
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" <del> parameter. </del> <ins> 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. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such
Change:
Section 4.2 The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. Consider being more precise by saying: NEW The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension (see 4.2.1.6 of [RFC5280]). Section 5. For these cases, the client simply sends a DNS SVCB query using the known name of the resolver. This query can be issued to the named Encrypted Resolver itself or to any other resolver. Unlike the case of bootstrapping from an Unencrypted Resolver (Section 4), these records SHOULD be available in the public DNS. If there was a limited domain mechanism using DDR, why would these records be in public DNS?

Discussion:
default system or application trust anchors. The client MUST verify that the certificate contains the IP <del> address of the designating Unencrypted Resolver in a subjectAltName extension. </del> <ins> address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension as described in Section 4.2.1.6 of RFC5280. </ins> If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the
Change:
Thanks for the painless read! Just a few trivial comments. Minor: The 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//

Discussion:
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 others records in the </del> <ins> Designated Resolver.  The client can still use other records in the </ins> 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

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" <del> 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. </del> <ins> 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. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such

This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC6761. <del> 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. </del> IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description
Change:
CC NAME I might suggest a slightly less binding wording where port 53 is concerned for the Unencrypted Resolver definition. Perhaps: "A DNS resolver using a transport without encryption, historically TCP or UDP port 53." I'd be in favor of using more RFC 8174 "SHOULD/SHOULD NOT" text in place of "ought [not] to". Specifically, for the text about address family support, consider perhaps something like: OLD: ... The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to support fewer. NEW: ... The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT support fewer. I wonder if it's good to require that clients MUST NOT/SHOULD NOT accept certificates claiming to be for URL This might be over-specifying things and/or it might be a check against some types of misconfigurations.

Discussion:
current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms. <del> A DNS resolver using TCP or UDP port 53 without encryption. </del> <ins> A DNS resolver using a transport without encryption, historically TCP or UDP port 53. </ins> 3.

address, it ought to provide an A record for an IPv4 address of the Designated Resolver; similarly, if it is accessible using an IPv6 address, it ought to provide a AAAA record for an IPv6 address of the <del> Designated Resolver.  The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to </del> <ins> Designated Resolver.  The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT </ins> support fewer.  If this is not done, clients that only have connectivity over one address family might not be able to access the Designated Resolver.
Change:
From Paul Wouters: From Michael Richardson:
Do you think this is a client configuration that we should reasonably expect? It seems to me that that behavior would be quite strange, although it is permissible. I think it's probably clearer for our examples to represent common configurations.
NAME Can we discuss it separately? This PR is for changes in response to feedback in the ADD adoption thread. Do you approve of this PR for that purpose? Perhaps you can open a new PR if you would like to add more example text.
Yes, changes look good to me. Works for me. I proposed this text to address the comment from the WG on whether client implementations will enable DNSSEC to support the proposed mechanism.

Discussion:
14 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document makes use of the terms defined in RFC8499.  The term "Global DNS" is defined in RFC8499. 'Encrypted DNS' refers to a DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DoT, DoH, or DoQ). The term 'Validated Split-Horizon' is also defined. 2.1. A split horizon configuration for some name is considered "validated" if the network client has confirmed that a parent of that name has authorized the local network to serve its own responses for that name.  Such authorization generally extends to the entire subtree of names below the authorization point. </del> <ins> This document makes use of the terms defined in RFC8499, e.g. "Global DNS".  The following additional terms are used throughout the document: </ins> 3.

6.1. <del> The client sends the NS query to a pre-configured resolver that is external to the network, over a secure transport.  Clients SHOULD apply whatever acceptance rules they would otherwise apply when using this resolver (e.g. checking the AD bit, validating RRSIGs). </del> <ins> This method applies only if the client is already configured with a default resolution strategy that sends queries to a resolver outside of the network over a secure transport.  That resolution strategy is considered "tamperproof" because any actor who could modify the NS response could already modify all of the user's other DNS responses. To ensure that this assumption holds, clients MUST NOT relax the acceptance rules they would otherwise apply when using this resolver. For example, if the client would check the AD bit or validate RRSIGs locally when using this resolver, it must also do so when resolving NS records for this purpose. </ins> 6.2.