jiebi/TextFlow huggingface dataset:
Original text:
This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from <del> unencrypted DNS to encrypted DNS when only the IP address of an encrypted resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </del>  known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. When only an IP address of an Unencrypted Resolver is known, the client queries a special use domain name to discover DNS SVCB <del> records associated with the Unencrypted Resolver (bootstrapping). </del>  <del> When the hostname of an encrypted DNS server is known, the client </del>  requests details by sending a query for a DNS SVCB record.  This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver

Reviewer comments:
I've made a few changes to terms used to correct some accidental lies: the starting IP address could be of an Encrypted Resolver, but does not have to be, discovery by SVCB may discover one or more resolver which may or may not be the original resolver, etc.

Revised text:
This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from  <ins> unencrypted DNS to encrypted DNS when only the IP address of a resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </ins> known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. When only an IP address of an Unencrypted Resolver is known, the client queries a special use domain name to discover DNS SVCB  <ins> records associated with one or more Encrypted Resolvers the Unencrypted Resolver has designated for use when support for DNS encryption is requested (bootstrapping). </ins>  <ins> When the hostname of an Encrypted Resolver is known, the client </ins> requests details by sending a query for a DNS SVCB record.  This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver
Original text:
When a client discovers Designated Resolvers, it learns information such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service <del> Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. </del>  The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- <del> D.schwartz-svcb-dns.  However, if any protocol does not involve some </del>  form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.

Reviewer comments:
Addressing
Once it's published, we should reference the official draft for draft-schwartz-svcb-dns

Revised text:
When a client discovers Designated Resolvers, it learns information such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service  <ins> 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. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I-  <ins> D.ietf-add-svcb-dns.  However, if any protocol does not involve some </ins> form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.
Original text:
resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a <del> certificate that claims ownership over both resolvers. </del>  1.1.

Reviewer comments:
We only require you to check the designated resolver IP so this text is now incorrect.
lgtm
How's this?
lgtm v2

Revised text:
resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a  <ins> certificate that claims ownership over the IP address for the original designating resolver. </ins> 1.1.
Original text:
Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism.  4.2. Verified Discovery is a mechanism that allows automatic use of a

Reviewer comments:
DDR designations, especially for/to non-public IP addresses, will break if cached across networks. Requirements and considerations need to be added to ensure correct behavior.
Closing with PR

Revised text:
Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. <ins> A client MUST NOT use a Designated Resolver designated by one Unencrypted Resolver in place of another Unencrypted Resolver.  As these are known only by IP address, this means each unique IP address used for unencrypted DNS requires its own designation discovery. This ensures queries are being sent to a party designated by the resolver originally being used. Generally, clients also SHOULD NOT reuse the Designated Resolver discovered from an Unencrypted Resolver over one network connection in place of the same Unencrypted Resolver on another network connection.  Instead, clients SHOULD repeat the discovery process on the other network connection. However, if a given Unencrypted Resolver designates a Designated Resolver that uses a public IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </ins> 4.2. Verified Discovery is a mechanism that allows automatic use of a
Original text:
preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https.  To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake.

Reviewer comments:
To address
We should clarify that if a client doesn’t understand a mandatory parameter in an SVCB record, it MUST NOT use it as normal DoT/DoH, since it could be misinterpreting the meaning.
Concrete example might be with: "mandatory=foo,dohpath foo=[...] alpn=h2 dohpath=[...]" Where clients which don't know how to handle "foo" must ignore that RR in the RRset, which might also contain other SVCB RRs for just DoH.

Revised text:
preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> 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. </ins> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake.
Original text:
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>  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>  The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa":

Reviewer comments:
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).

Revised text:
When a client discovers Designated Resolvers, it learns information such as the supported protocols and ports.  This information is  <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  <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":
Original text:
be configured to present the appropriate TLS certificate when no SNI is present for both DoT and DoH.  7. Since clients can receive DNS SVCB answers over unencrypted DNS, on-

Reviewer comments:
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.

Revised text:
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-
Original text:
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 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. 

Reviewer comments:
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

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

Reviewer comments:
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

Revised text:
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  <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
Original text:
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>  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

Reviewer comments:
But all bets are off with trust anchors outside of the WebPKI. (Plus a small tweak to the next paragraph.)

Revised text:
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,  <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
Original text:
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>  While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such

Reviewer comments:
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

Revised text:
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"  <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
Original text:
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>  If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the

Reviewer comments:
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?

Revised text:
default system or application trust anchors. The client MUST verify that the certificate contains the IP  <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
Original text:
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>  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>  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.

Reviewer comments:
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.

Revised text:
current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms.  <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  <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.