jiebi/CodeConvo huggingface dataset:
Change:
… issue
It is not stated crystal clear in the -01 draft if there's only one DNS packet per HTTP request or if it is allowed to send more than one. Some wordings (like ) suggest a single packet. I think it would benefit the document to be more explicit on this detail.
good point - it is meant to be one, otherwise blocking and reordering (which is resolved at the intra-request http level) would be a problem. we'll add text.

Discussion:
This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for <del> integrity and confidentiality). </del> <ins> integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses

DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. <del> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. </del> <ins> A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header

Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> A DNS response may contain a set of DNS Resource Records each with its own Time To Live (TTL) freshness information.  The freshness lifetime (RFC7234 Section 4.2) of the HTTP response should be coordinated with the Resource Record bearing the smallest TTL in the response.  The freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del> <ins> The Answer section of a DNS response contains one or more RRsets. (RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic
Change:
recently I've left the ack section mostly untouched until the final (or near final) edit. Easier to deal with it once. However I think its good idea to have leave the PR open and amend it as useful
OK, having a "living" PR seems OK.

Discussion:
10. <del> Joe Hildebrand contributed lots of material for a different iteration of this document.  Helpful early comments were given by Ben Schwartz and Mark Nottingham. </del> <ins> This work required a high level of cooperation between experts in different technologies.  Thank you Ray Bellis, Stephane Bortzmeyer, Manu Bretelle, Tony Finch, Daniel Kahn Gilmor, Olafur Guomundsson, Wes Hardaker, Rory Hewitt, Joe Hildebrand, David Lawrence, Eliot Lear, John Mattson, Alex Mayrhofer, Mark Nottingham, Jim Reid, Adam Roach, Ben Schwartz, Davey Song, Daniel Stenberg, Andrew Sullivan, Martin Thomson, and Sam Weiler. </ins> 11.  References
Change:
Reverts dohwg/draft-ietf-doh-dns-over-https

Discussion:
9. <del> DNS over HTTPS relies on the underlying HTTPS connection to provide confidentiality.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for confidential transport. </del> <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with

RFC7540 provide some further advice on mitigations within an HTTP/2 context. <del> The HTTPS connection also authenticates the DNS API server but does not inherently assure of authenticity of DNS data.  A DNS API client may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recurvise DNS resolver.  A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server. </del> [[ From the WG charter: The working group will analyze the security and privacy issues that
Change:
…
during the singapore meeting tale noted that the http caching model, where 1 lifetime is assigned to the rrset is not necessarily the way a dns cache would handle things.. each rr can have its own ttl (though one dns implementation does it this way). perhaps worth some explanatory text when talking about rrset granularity and http caches.

Discussion:
(RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can <del> have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del> <ins> have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic
Change:
In order to prevent a dependency on traditional DNS or a DNS query for CRL/OCSP certificate validation check, OCSP stapling should be used for the HTTPS web server.
we're probably better off describing the potential deadlock in revocation and mentioning stapling as a best practice.. but in general I think we want to stay away from specifying a whole lot of how-to-profile-https details as these things do differ between clients and we tend to accept all of the variants as "https".. for e.g.

Discussion:
Server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <ins> Many HTTPS implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this can happen.  DNS API servers SHOULD utilize OCSP Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration
Change:
Unfortunately, we shouldn't use the existing real-world URL address and should be using example ip space instead.
unfortunately you included the PR changes in this PR too.. let's see if the merge process can sort that out :)
ok! thanks.

Discussion:
This is an example response for a query for the IN A records for "www.example.com" with recursion turned on.  The response bears one <del> record with an address of 93.184.216.34 and a TTL of 128 seconds. </del> <ins> record with an address of 192.0.2.1 and a TTL of 128 seconds. </ins> 7.
Change:
Right now the text only defines that future edns options must be supported, but (IMHO) we should support all future versions of changes to the DNS in general, not just future EDNS extensions. So I proposed text that rewords a bit to state this and uses EDNS as an example.
Good call. There might be other on-the-wire extension mechanisms in the future.

Discussion:
The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to <del> contain one or more EDNS extensions, including those not yet defined. </del> <ins> contain future modifications to the DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.
Change:
Firstly, mention that the URI can be anything. Then explain why the well-known exists. The well-known URI exists for two reasons: to aid in discovery, for cases where the discovery process produces only a domain name (or domain name and port) to contextualize server pushes The first doesn't need a SHOULD.
The draft gets stuck into describing pieces of the URL, but neglects to point out some obvious things, like what the URL is for. It could probably use some more clarity about the configuration and discovery point as well.

Discussion:
5. <ins> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. </ins> The URI scheme MUST be https. <del> The path SHOULD be "/.well-known/dns-query" but a different path can be used if the DNS API Client has prior knowledge about a DNS API service on a different path at the origin being used.  (See iana for the registration of this in the well-known URI registry.)  Using the well-known path allows automated discovery of a DNS API Service, and also helps contextualize DNS Query requests pushed over an active HTTP/2 connection. </del> <ins> A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. </ins> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods.
Change:
and
The draft says: But it probably needs to describe at least one way to perform that automated discovery. It's probably not a good idea to have people attempt to guess.
fwiw the .wk is used here so that that when a request/response pair is pushed the client understands this to be DoH. Its probably also helpful to have a well-known path here for the normal so that defaults of https://, 443, and the default path can be used in configuration systems that might only be capable of a hostname. (e.g. my DoH server is at URL).. I'll work on text.
I think I can future proof for the context I want using a response header instead of a well known.. imo that's kind of ignoring the point of the path - but whatever. Maybe I'll propose x-well-known :)

Discussion:
5. <del> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. The URI scheme MUST be https. A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST methods. </del> <ins> To make a DNS API query a DNS API client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.  The DNS API server defines the URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header

These examples use HTTP/2 style formatting from RFC7540. <del> For this example assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well- known path.  The DNS API client chooses to send its requests in application/dns-udpwirefomat but indicates it can parse replies in that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> These examples use a DNS API service located at https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </ins> The same DNS query, using the POST method would be:

8.1. <del> This specification registers a Well-Known URI RFC5785: URI Suffix: dns-query Change Controller: IETF Specification Document(s): [this specification] 8.2. </del> 9. Running DNS over HTTPS relies on the security of the underlying HTTP
Change:
partially addresses martin is right - the naming of this query parameter was just asking for pain. new coat of paint is in order.
:+1:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.

Discussion:
When using the GET method the URI path MUST contain a query parameter with the name of "ct" and a value indicating the media-format used <del> for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be </del> <ins> for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be </ins> empty.  An empty value indicates the default application/dns- <del> udpwireformat type (e.g. ct&body=...). </del> <ins> udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter <del> with the name of "body".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. </del> <ins> with the name of "dns".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. </ins> Specifications that define media types for use with DOH, such as DNS Wire Format dnswire of this document, MUST indicate if the body parameter uses base64url encoding.

The body is the DNS on-the-wire format defined in RFC1035. When using the GET method, the body MUST be encoded with base64url <del> RFC4648. Padding characters for base64url MUST NOT be included. </del> <ins> RFC4648 and then placed as a name value pair in the query portion of the URI with name "dns".  Padding characters for base64url MUST NOT be included. </ins> When using the POST method, the body MUST NOT be encoded.
Change:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.

Discussion:
These examples use HTTP/2 style formatting from RFC7540. These examples use a DNS API service located at <del> https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> https://dnsserver.example.net/dns-query to resolve the IN A records. </ins> <del> The same DNS query, using the POST method would be: </del> <ins> The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. The first example request uses GET to request www.example.com The same DNS query for www.example.com, using the POST method would be: Finally, a GET based query for a.62characterlabel-makes-base64url- distinct-from-standard-base64.example.com is shown as an example to emphasize that the encoding alphabet of base64url is different than regular base64 and that padding is omitted. The DNS query is 94 bytes represented by the following hex encoding </ins> 6.
Change:
The discussion of Accept: header tries too hard to suggest that there will be future formats. We don't actually know that, and the examples in the current draft have confused some developers. See PR URL
Yep, easier to narrow this down than address the implied questions.

Discussion:
https://dnsserver.example.net/dns-query to resolve the IN A records. The requests are represented as application/dns-udpwirefomat typed <del> bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> bodies. </ins> The first example request uses GET to request www.example.com

At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del> <ins> "application/dns-udpwireformat", but it is possible that other response formats will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS extensions, depending on the extension
Change:
…ry parameter
The spec refers to "query parameters", but does not specify their syntax. The most current reference for its definition is: URL
If you take , then you conveniently avoid having to normatively reference that specification :)

Discussion:
smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter <del> with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&dns=...). </del> <ins> name-value pair QUERYPARAMETER with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns- udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns-udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter with the name of "dns".  The value of the parameter is the content of
Change:
... says: """ DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. """ Do we need to be talking about the motivation here? The way it's written sounds like it's using HTTP for tunnelling, which is something we wanted to avoid (especially if future efforts take away the message that HTTPS is the best tunnel).
I think the introduction does a decent job of dealing with the "not just a tunnel" question.. and therefore these motivators can live there and we can have a very simple 1 line abstract. (cutting non normative text is in vogue).. so I'll put up a PR that reflects that.

Discussion:
Abstract <del> DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication.  Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. </del> This document describes how to run DNS service over HTTP using https:// URIs.
Change:
we can provide a reminder that http is stateless and therefore reordering happens so don't use doh for a session protocol.

Discussion:
API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. <ins> HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration