jiebi/CodeConvo huggingface dataset:
Code change:
Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

Related discussion:
text: to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins> 8. 8.1.
Code change:
NAME does this work for you?
OK, so I said LGTM, but how does a server know that it is such a server? Can't I just publish a random DDR record for 1.1.1.1?
As I mentioned in the session, this is partly covered in SVCB-DNS, but perhaps we need a tighter rule. I've opened an issue to discuss it: URL I'm not entirely sure which draft this kind of text ought to go in. If you think this logic applies beyond DDR (e.g. in ADoT cases), then it probably should go in the SVCB-DNS draft. Otherwise, maybe DDR is the place.
NAME for security considerations, I'm OK with multiple drafts having warnings. I think this particular attack should be mentioned in DDR, since other uses of DNS SVCB could be over more trusted channels.
NAME if your resolver responds to URL, then we expect the address of the resolver I asked to be covered in the cert. So, if I send a packet to 1.1.1.1, 1.1.1.1 has to be covered. So, if you just provide a "random" DDR record in response to URL, you can only point to some resolver that has your IP address in its cert, which presumably is sufficient coordination for the resolver to "know" it has this set up.
Right. Good point.
As mentioned at the microphone, if we are to allow the query-path to be specified in the clear like this, we need to require that servers not have different responses with different query paths.
LGTM

Related discussion:
text: queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. <ins> 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. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections
Code change:
Closes URL
Allowing the use of nonstandard port numbers in SVCB for DNS provides valuable operational flexibility, but it also creates a risk related to cross-protocol confusion attacks, in which a malicious server convinces a client to send TCP contents that can be misparsed as a different protocol by a non-TLS victim server. For example, a malicious DNS server could indicate an SNI or session ticket that can be misparsed as a command by a recipient server, and use DNS rebinding to change its own apparent IP address to the victim server. Clients would then send this server-controlled payload to the victim server. This is dangerous if the client is implicitly authorized to control the victim server (e.g. authorization by IP address). Note that only DoT and DoH (over TCP) are amenable to these attacks. QUIC Initial encryption ensures that the packet has no meaning to a recipient that is not QUIC-aware, and any QUIC-aware recipient should not be vulnerable to these attacks. We should consider ways to minimize the impact of these attacks. For example, we could require clients to restrict the value of the parameter to a small fixed list, or refer to the . Credit to NAME

Related discussion:
text: This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) <ins> Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: The client is being used with a DNS server that it trusts not attempt this attack. The client is being used in a context where implicit elevated access cannot apply. The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from the "Port blocking" section of FETCH). </ins> 4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without
Code change:
…out presence of glue in zones.
No further discussion on list nor here so I will merge this.
From the dnsop list, Ralf Weber suggests the draft could more clearly state that a name server might provide an "incorrect" response because it wasn't given necessary glue records in the zone data.

Related discussion:
text: defined for the DNS. Note that this document only clarifies requirements of name server <del> software implementations.  It does not change any requirements on data placed in DNS zones or registries. </del> <ins> software implementations.  It does not introduce or change any requirements on data placed in DNS zones or registries.  In other words, this document only makes requirements on "available glue records" (i.e., those given in a zone), but does not make requirements regarding their presence in a zone.  If some glue records are absent from a given zone, an authoritative name server may be unable to return a useful referral response for the corresponding domain.  The IETF may want to consider a separate update to the requirements for including glue in zone data, beyond those given in RFC1034 and RFC1035. </ins> 1.1.
Code change:
…empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL

Related discussion:
text: 5. This section defines the terms used for the systems that act as DNS <del> clients, DNS servers, or both. </del> <ins> clients, DNS servers, or both.  In the RFCs, DNS servers are sometimes called "name servers", "nameservers", or just "servers". There is no formal definition of DNS server, but the RFCs generally assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in RFC1035 and its successors. </ins> For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root
Code change:
…empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL

Related discussion:
text: of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. <ins> A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but
Code change:
This is part of the previous pull request, but I missed it because it was interleaved with some unrelated changes.

Related discussion:
text: simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The <del> details of how SRP server(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </del> <ins> details of how SRP registrar(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </ins> mechanism here. <del> SRP clients on constrained networks are expected to receive from the network a list of SRP servers with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP server addresses.  It is the responsibility of the SRP server supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </del> <ins> SRP requestors on constrained networks are expected to receive from the network a list of SRP registrars with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP registrar addresses.  It is the responsibility of the SRP registrar supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </ins> 2.1.3.
Code change:
The set of constraints for the host description includes a constrain that A and AAAA records must be of sufficient scope. This is asking a bit much of the SRP server, which may or may not be able to make this determination. There may also be cases where an SRP registration with an address of less than global scope is useful. Consequently, this constraint is removed, and text added to talk about how servers should deal with addresses of less-than-global scope.

Related discussion:
text: An instruction is a Host Description Instruction if, for the appropriate hostname, it contains <ins> A and/or AAAA records that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses. For example, if a link-scope address or IPv4 autoconfiguration address is provided by the SRP requestor, the SRP registrar could not publish this in a DNS zone.  However, in some situations, the SRP registrar may make the records available through a mechanism such as an advertising proxy only on the specific link from which the SRP update originated; in such a situation, locally-scoped records are still valid. </ins> 2.3.2. An SRP Update MUST include zero or more Service Discovery
Code change:
Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Related discussion:
text: record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del> <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the
Code change:
Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Related discussion:
text: Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an <del> EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </del> <ins> EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </ins> These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: There are two primary use cases for this protocol. <del> The primary one is to prevent on-path network devices from </del> <ins> The primary use case is to prevent on-path network devices from </ins> interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del> <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del> <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: defined. The protocol must use a secure transport that meets the <del> requirements for modern https://. </del> <ins> requirements for modern HTTPS. </ins> 4.1.
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: 5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del> <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: At the time this is published, the response types are works in progress.  The only known response type is "application/dns- <del> udpwireformat", but it is likely that at least one JSON-based </del> <ins> udpwireformat", but it is possible that at least one JSON-based </ins> response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY