jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-add-ddr

Commentary: In 6.3 we say : " When performing discovery using resolver IP addresses , clients MUST use the IP address as the URI host for DoH requests . " There are multiple IP addresses that may be in - play here . We should clarify which is " the IP address " in the case where the Designated Resolver and the Unencrypted Resolver do NOT share an IP . ( I take it that this is the IP of the Unencrypted Resolver ? ) 
 Good point ! 
 LGTM
When performing discovery using resolver IP addresses, clients MUST
use the IP address as the URI host for DoH requests.
When performing discovery using resolver IP addresses, clients MUST
use the original IP address of the Unencrypted DNS Resolver as the
URI host for DoH requests.
Draft: draft-ietf-add-ddr

Commentary: … tion 
 Section 4.2 , verified , calls out the entire cert check for validation , but section 4.3 , opportunistic , only talks about skipping the IP validation . It has gone without saying that these are equivalent because the IP is the only thing about the cert being validated , but for implementors , does this mean they can skip the entire cert validation process ( meaning the connection will be used even if other errors occur , such as the cert being expired ) ? I assume yes ( no cert checking of any kind ) , but we should be specific . 
 I think it 's up to implementations . If I look at the opportunistic profile in RFC 7858 , it say : I think we should point to that and explain that it 's open to the client to determine how opportunistic it wants to be 
 LGTM
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
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
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 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.
An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of
RFC7858 as a mode in which clients do not validate the name of the
resolver presented in the certificate.  This Opportunistic Privacy
Profile similarly applies to DoQ RFC9250.  For this profile,
Section 4.1 of RFC7858 explains that clients might or might not
validate the resolver; however, even if clients choose to perform
some certificate validation checks, they will not be able to validate
the names presented in the SubjectAlternativeName field of the
certificate for private and local IP addresses.
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.
Draft: draft-ietf-add-ddr

Commentary: CC 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 This might be over - specifying things and/or it might be a check against some types of misconfigurations .
A DNS resolver using TCP or UDP port 53 without encryption.
A DNS resolver using a transport without encryption, historically
TCP or UDP port 53.
Designated Resolvers SHOULD be accessible using the IP address
families that are supported by their associated Unencrypted
Resolvers.  If an Unencrypted Resolver is accessible using an IPv4
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
Designated Resolver.  The Designated Resolver can support more
address families than the Unencrypted Resolver, but it ought not to
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.
Designated Resolvers SHOULD be accessible using the IP address
families that are supported by their associated Unencrypted
Resolvers.  If an Unencrypted Resolver is accessible using an IPv4
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
Designated Resolver.  The Designated Resolver MAY support more
address families than the Unencrypted Resolver, but it SHOULD NOT
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.
Draft: draft-ietf-add-ddr

Commentary: 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 ?
The client MUST verify that the certificate contains the IP
address of the designating Unencrypted Resolver in a
subjectAltName extension.
The client MUST verify that the certificate contains the IP
address of the designating Unencrypted Resolver in an iPAddress
entry of the subjectAltName extension as described in
Section 4.2.1.6 of RFC5280.
Draft: draft-ietf-add-ddr

Commentary: 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/{dns } " is considered something that the DoH resolver needs to identify and recover from ? Or , is this more narrow in that a DoH server can not 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 can not offer more than one DoH service on the same IP address ( where DDR does n'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 does n't mean you ca n'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 : 
 See also : 
 please see 
 Thanks this is an improvement . LGTM
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.
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.
Draft: draft-ietf-add-ddr

Commentary: 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 . 
 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 for the IP reference identity might be needed to cover the SAN validation piece . RFC 6125bis does n'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 does n't cite Section 6 of RFC 5280 . It should , and it is probably my fault that it does n'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 is n't too much to ask . 
 take a look at the proposed text 
 LGTM
In order to be considered a verified Designated Resolver, the TLS
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
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
record's Time to Live (TTL).
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
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
record's Time to Live (TTL).
Draft: draft-ietf-add-ddr

Commentary: Might as well be clearer .
Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
packets.  Clients should be aware that it might not be possible to
distinguish between resolvers that do not have any Designated
Resolver and such an active attack.  To limit the impact of discovery
queries being dropped either maliciously or unintentionally, clients
can re-send their SVCB queries periodically.
Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
queries or answers.  Clients should be aware that it might not be
possible to distinguish between resolvers that do not have any
Designated Resolver and such an active attack.  To limit the impact
of discovery queries being dropped either maliciously or
unintentionally, clients can re-send their SVCB queries periodically.
Draft: draft-ietf-add-ddr

Commentary: But all bets are off with trust anchors outside of the WebPKI . ( Plus a small tweak to the next paragraph . )
There are situations where Verified Discovery of encrypted DNS
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,
whose identity cannot be confirmed using TLS certificates.
There are situations where Verified Discovery of encrypted DNS
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,
whose identity cannot be confirmed using TLS certificates under most
conditions.
Draft: draft-ietf-add-ddr

Commentary: There 's a lot of redundancy in this draft , but this might help .
If the recursive resolver that receives this query has one or more
Designated Resolvers, it will return the corresponding SVCB records.
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
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
Encrypted Resolver until an additional DNS lookup for the A and AAAA
records can be made to the Unencrypted Resolver (or some other
resolver the DNS client has been configured to use).
If the recursive resolver that receives this query has one or more
Designated Resolvers, it will return the corresponding SVCB records.
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 save the DNS client an additional round trip to retrieve the
address of the designated resolver; see Section 5 of I-D.ietf-dnsop-
svcb-https.
Draft: draft-ietf-add-ddr

Commentary: 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
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 blind
forwarder MAY choose to forward these queries when the operator
expects that this does not apply, either because the operator knows
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.
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 blind
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 resolver to use the SVCB information
opportunistically.
Draft: draft-ietf-add-ddr

Commentary: Addressing 
 I 've bravely stolen some text to meet the additional IANA request . 
 Resolvers will normally return NXDOMAIN for queries that do n'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 is n't enough for resolvers to synthesize a SVCB response for they also have to synthesize a NOERROR response for any other QTYPE on that name . The draft should probably mention that . Credit to for noticing this . 
 agreed that we could note this , but it 's also expected that a client would n't be sending out queries for other types on , 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
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.
Draft: draft-ietf-add-ddr

Commentary: From WGLC ,  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   , or if a network provisioning protocol ( such as DHCP or IPv6   ) provides a name for an Encrypted Resolver alongside the resolver IP address .
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).
Draft: draft-ietf-add-ddr

Commentary: 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 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 ) .
When a client discovers Designated Resolvers, it learns information
such as the supported protocols and ports.  This information is
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.
When a client discovers Designated Resolvers, it learns information
such as the supported protocols and ports.  This information is
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.
Because this query is for an SUDN, which no entity can claim
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.
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 or
used to construct the DoH template MUST be provided.
Draft: draft-ietf-add-ddr

Commentary: To address 
 We should clarify that if a client does n’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 do n't know how to handle " foo " must ignore that RR in the RRset , which might also contain other SVCB RRs for just DoH.
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.