The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "application/dns-udpwireformat" (See dnswire) responses but MAY also process any other type it receives. </del>  In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as application/dns-udpwireformat, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del>  DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them. "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as application/dns-udpwirefomat typed bodies. </del>  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 other response formats will be defined in the future. </del>  <del> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del>  Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process application/dns- udpwireformat request messages. </del>  A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to 5.4. In order to maximize interoperability, DNS API clients and DNS API <del> servers MUST support the "application/dns-udpwireformat" media type. Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </del>  6. DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. <del> The media type is "application/dns-udpwireformat". </del>  7.

The media type has been the subject of some debate. The above might be the best I've seen.

The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client  <ins> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media  <ins> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them. "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records.  <ins> The requests are represented as message/dns typed 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  <ins> "message/dns", but it is possible that other response formats will be defined in the future. </ins>  <ins> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's caching discusses the relationship between DNS and HTTP response caching.  <ins> A DNS API server MUST be able to process message/dns request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to 5.4. In order to maximize interoperability, DNS API clients and DNS API  <ins> servers MUST support the "message/dns" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 6. DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request.  <ins> The media type is "message/dns". </ins> 7.


development.  They included preventing on-path devices from interfering with DNS operations and allowing web applications to access DNS information via existing browser APIs in a safe way <del> consistent with Cross Origin Resource Sharing (CORS) CORS.  There are certainly other uses for this work. </del>  2.

When a statement is so definite, the reader tends to assume that there is something more to be said. In this case, the obvious question is "what other uses are there?", closely followed by "and what reason could the authors have had for not mentioning them?"

development.  They included preventing on-path devices from interfering with DNS operations and allowing web applications to access DNS information via existing browser APIs in a safe way  <ins> consistent with Cross Origin Resource Sharing (CORS) CORS.  No special effort has been taken to enable or prevent application to other use cases. </ins> 2.


2. <del> A server that supports this protocol on one or more URIs is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </del>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

This isn't necessary. I realize that this reverts a deliberate change as part of , but if it is important to describe - which I don't think helps - then I don't think that this is the right approach. Adding an explicit statement would be better.
hmm.. I think this was committed a little prematurely.. as martin says, the change was originally deliberate to emphasize that uris are the primitive and not the server. Happy to make that an explicit statement - but don't want to leave it out.

2.  <ins> A server that supports this protocol is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and


contain the RFC7234 Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response.  DNS API clients should subtract this time from the DNS <del> TTL if they are re-sharing the information in a non HTTP context (e.g., their own DNS cache) to determine the remaining time to live of the DNS record. </del>  HTTP revalidation (e.g., via If-None-Match request headers) of cached DNS information may be of limited value to DOH as revalidation

URL unnecessary. The point here is to highlight the need to tweak the TTL to account for Age, not to go into why. It's actually a generic requirement that is not specific to translation to other contexts.

contain the RFC7234 Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response.  DNS API clients should subtract this time from the DNS  <ins> TTL in each RRset to determine the time remaining on the TTL. </ins> HTTP revalidation (e.g., via If-None-Match request headers) of cached DNS information may be of limited value to DOH as revalidation


5.2. <del> The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. </del>  The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs

what motivates this? Is it just the word minimum? It changes from normative to non-normative which is a pretty big change and doesn't reflect, imo, the consensus we had in singapore.
I see NAME s mail now - but I think its in the rough at least with the current text being too strong (rewording welcome). There was considerable discussion about h2 really being necessary to make this work well - there are just practical considerations to being able to always deploy that.. therefore SHOULD (and the reason you wouldn't is its impractical to know or enforce version levels across a chain of infrastructure).
This sounds significant enough to be discussed on the list.

5.2.  <ins> HTTP/2 RFC7540 is the minimum RECOMMENDED version of HTTP for use with DOH. </ins> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs


between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. <del> If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for the query and is providing the best answer it could get.  This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </del>  Many extensions to DNS, using RFC6891, have been defined over the years.  Extensions that are specific to the choice of transport, such

Attempt to deal with . I'm not convinced that this is much better than the current text, but it might help others.
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.

between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering.  <ins> A DNS API server is allowed to answer queries with any valid DNS response.  For example, a valid DNS response might have the TC (truncation) bit set in the DNS header to indicate that the server was not able to retrieve a full answer for the query but is providing the best answer it could get.  A DNS API server can reply to queries with an HTTP error for queries that it cannot fulfill.  In this same example, a DNS API server could use an HTTP error instead of a non- error response that has the TC bit set. </ins> Many extensions to DNS, using RFC6891, have been defined over the years.  Extensions that are specific to the choice of transport, such


HTTP. In the absence of information about the authenticity of responses, <del> such as DNSSEC, a DNS API server can poison a client's cache.  A client MUST NOT authorize arbitrary DNS API servers.  Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </del>  A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP

This is the only place where a client cache is mentioned, and stub resolvers normally don't have caches. (Some browsers have caches for the stub resolvers, but this is rare and not well known outside a small group of people.) This change replaces that one instance with wording that still explains the main problem.

HTTP. In the absence of information about the authenticity of responses,  <ins> such as DNSSEC, a DNS API server can give a client invalid data in responses.  A client MUST NOT authorize arbitrary DNS API servers. Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP


6.1. <del> A DNS API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "no-cache" Cache-Control directive; however DNS caches do not have a similar mechanism. The Answer section of a DNS response can contain zero or more RRsets. (RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset has Time To Live (TTL) freshness information. Different RRsets in the Answer section can have different TTLs, although 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 RRset with the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS resource records in the Answer section reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response. </del>  If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from <del> that SOA record.  (See RFC2308.)  Otherwise, the HTTP response MUST set a freshness lifetime (RFC7234 Section 4.2) of 0 by using a mechanism such as the "no-cache" Cache-Control directive (RFC7234 Section 5.2.1.4). A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. A DOH response that was previously stored in an HTTP cache will contain the RFC7234 Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response.  DNS API clients should subtract this time from the DNS TTL in each RRset to determine the time remaining on the TTL. HTTP revalidation (e.g., via If-None-Match request headers) of cached DNS information may be of limited value to DOH as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound.  Furthermore, the HTTP response headers that enable revalidation (such as "Last-Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary RFC7541.  Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. DNS API servers may wish to consider whether providing these validation enabling response headers is worthwhile. The "stale-while-revalidate" and "stale-if-error" Cache-Control </del>  directives (RFC5861) could be well suited to a DOH implementation when allowed by server policy.  Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer <del> fresh. All HTTP servers, including DNS API servers, need to consider cache interaction when they generate responses that are not globally valid. For instance, if a DNS API server customized a response based on the client's identity then it would not want to globally allow reuse of that response.  This could be accomplished through a variety of HTTP techniques such as a Cache-Control max-age of 0, or perhaps by the Vary response header. </del>  6.2.

In reading this a second time through, I wonder what value there is in matching the freshness lifetime to the TTL? The implicit assumption here is that it is important that a cache never serve a response that includes an expired RRset. This simplifies the implementation of a client, but it also means that it tends to make client's stupid. That is, they might not use RRsets that are still valid from the perspective of their TTL, simply because they are no longer in cache. It might be better to have the DNS code that uses the RRset being responsible for checking the TTL. HTTP will ensure that the time that the RRset was generated is faithfully recorded and transferred with the response, so that should be enough. It potentially allows use of old responses for RRsets that are still valid. Finally, the mention of stale-while-revalidate and stale-if-error actually suggests that this requirement is more. These operate outside of the freshness lifetime.
I think it's important that DOH be usable with standard (non-DOH-aware) HTTP caches. Allowing the cache lifetime to exceed the shortest TTL might make it impossible to use DOH through such a cache: the client cannot flush the cache, and the cache entry might not expire until after its longest TTL.
+1 to NAME response.
Clients can always set Cache-Control: no-cache and avoid the cache. The point here is that the TTL is the authoritative value. Insisting on HTTP matching that both loses fidelity (multiple RRsets have different TTLs) and encourages lazy implementation of clients.
Agree with everyone. I would say that a server/parser could in that case imagine to set a "retry-after:60 " HTTP header (corresponding to the lower TTL in this example RR); when TTL < RR situation verifies (simple calculation, t0 plus lowest values in RR), a "vary: retry-after" header could control the re-freshing of object (aka, force refresh sometimes but do still do cache in the meantime). By the way, some ISP's DNS used to generally override all TTL that were lower than 60 seconds, used to be even 300 seconds. meeting halfway between some cache and good reachability/redundancy would be good enough (TTL real value is to support/improve the service continuity/validity. TTL mission is not guessing how long a service would keep being available, or running). Some services as Skype would get such cache crazy, due to 5 to 30 seconds TTL.... a choice must be done somewhere between precision and performances.. An average HTTP cache lasts between minutes and days, say everywhere from 1 to 8 hours in proxy administration praxis, 24 hours max. 24 hours in DNS terms is unacceptable. How accurately will the HTML programmer choose such blind-validity duration? In some ways, choosing HTTP validity exactly the same as the choiche of TTL for a given record, a pure bet !! Caching is one of the pillars of DOH in terms of speed and HTTP-friendliness. As one of the goals is (i believe) creating and populating a global valid cache through HTTP (as alternative or complement of existing DNS cache), doing no-cache is also a bit "against" the principle. but still a feature for privacy amateurs. I see value in HTTP cache also in case of DDoS; HTTP/DOH cache could represent a good fallback/backup of DNS data anyway, and HTTP is proved more resilent to flooding. One of the goals of DOH is to leverage use of existing infrastructures ! URL et URL
NAME In that case, setting is the only way a client can make sure that it actually gets non-expired answers. This creates a strong incentive, in both performance and complexity, to set on all DOH requests, defeating HTTP caching altogether. Yikes!
I favor keeping the current arrangement. A server that wishes to avoid the crux of the issue (i.e. that HTTP has one TTL, but the DNS response is a set of TTLs) can decompose response into multiple HTTP responses using HTTP/2 push each with their own TTLs. That seems like the right approach. I have a pretty strong inclination that the principle of least surprise says data in a successful HTTP response can always be used one time (but not reused) even if you don't implement any caching logic. I know your suggestion doesn't technically infringe on that - its more of a requirement on the processing of the response- but it seems like a much more fragile alignment. and I think NAME is on to something important with cache interop.
My .02 - I think that the advice in the current draft is good -- but it's just advice, and shouldn't have RFC2119 requirements associated with it. From the current markdown: Under what conditions can this SHOULD be violated? What is a client to do when it encounters a violation? Suggest "Specifically, the HTTP freshness lifetime should generally be set..." As above, there may be cases where this is desirable. Suggest "Be aware that if the response freshness lifetime is greater than that indicated by the DNS resource record with the smallest TTL in the response, HTTP caches can store those records for longer than they are valid for; clients can request a fresh HTTP response (e.g., using the Cache-Control: no-cache request directive) in this situation, but this can add latency." Question: should we say anything about whether a DOH client can use a stale HTTP response, and the conditions under which it should? As above. This is really vague for a MUST. implies ; is that required? Also, what is the otherwise applying to -- is this all responses that have no records in the answer section and no records in the DNS response? Many DNS API clients won't have any control over the heuristics that their (or an upstream) cache applies; this isn't an enforceable requirement.
NAME beat me to it. I think that we're making suggestions, not interoperability requirements. I would prefer to have no freshness information (and rely on heuristics) than to recommend marking things uncacheable. I think that the rules are similar to using (and inflating) TTL. Saying nothing might be easiest.
Under no circumstances does an HTTP client have to expect that a server may serve it an expired response out of cache, and recover by retrying with caching disabled. Under no circumstance does a DNS client have to expect that a recursive may serve it an expired response, and recover by bypassing the recursive cache somehow. There's a good reason for this: this architecture is complex, adds latency, and encourages the client to abandon caching rather than accept the complexity and retry latency. I do not think we can reasonably accept a specification that puts DOH clients in this position. To be clear, this is an interoperability question. A server that adopts a longer-than-min-TTL policy and a simple client (e.g. any existing client) are not interoperable.
longer-than-min-TTL is not significantly different to a DNS server extending the TTL. It's not advisable, but it still happens. The difference is that HTTP makes this visible, where DNS does not. A client that makes a request can reasonably use the response without checking either freshness lifetime or TTL.
The current doc states "The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response." I am guessing that this and any other similar text should refer to RRSet not RR.
I really hate the "A DOH response that was previously stored in an HTTP cache will contain the {{RFC7234}} Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response. DNS API clients should subtract this time from the DNS TTL in each RRset to determine the time remaining on the TTL." in DNS that is the job of the cache not the client. Or do you want to support DNS unaware HTTP caches?
yes - that's part of using http as the substrate..
I agree: in both cases, it is a protocol violation. The fact that some recursive resolvers fail to implement the DNS protocol does not mean that we need to endorse their incorrect behavior. If they want to violate RFC 1035, they can equally well violate DOH. The fact that these violations usually mostly work in practice is all the more reason to be clear about the designed behavior, because people who get it wrong won't notice for a long time. Perhaps we should state this normatively.
Hear hear. Exactly the point I was about to make.
Please take this all to the mailing list. I have (again) opened up a topic there.
I'm just reopening this because I use the github issues list as an editorial punchlist - not a comment about where to discuss :)
OK, but the rest of you: please don't comment here, but please do comment on the list. Thanks!
that is answered in the next sentence: "The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response. " its basically saying you SHOULD make HTTP and DNS match, but if you can't do that (because perhaps your code module can't fully parse DNS) you can do something like max-age = 0
I will soon commit as my best interpretation of the discussion (here and on the mailling list) It accepts most of Mark's changes but preserves the normative language and adds back a couple of small things that were the result of previous explicit working group requests (e.g. noting that cache busting is not something that can be done easily to a DNS-only cache).
Seems mostly good, but see 725ad7a for my edits.

6.1.  <ins> A DOH exchange can pass through a hierarchy of caches that include both HTTP and DNS specific caches.  These caches may exist beteen the DNS API server and client, or on the DNS API client itself.  HTTP caches are by design generic; that is, they do not understand this protocol.  Even if a DNS API client has modified its cache implementation to be aware of DOH semantics, it does not follow that all upstream caches (for example, inline proxies, server-side gateways and Content Delivery Networks) will be. As a result, DNS API servers need to carefully consider the HTTP caching metadata they send in response to GET requests (POST requests are not cacheable unless specific response headers are sent; this is not widely implemented, and not advised for DOH). In particular, DNS API servers SHOULD assign an explicit freshness lifetime (RFC7234 Section 4.2) so that the DNS API client is more likely to use fresh DNS data.  This requirement is due to HTTP caches being able to assign their own heuristic freshness (such as that described in RFC7234 Section 4.2.2), which would take control of the cache contents out of the hands of the DNS API server. The assigned freshness lifetime of a DOH HTTP response SHOULD be the smallest TTL in the Answer section of the DNS response.  For example, if a HTTP response carries three RRsets with TTLs of 30, 600, and 300, the HTTP freshness lifetime should be 30 seconds (which could be specified as "Cache-Control: max-age=30").  The assigned freshness lifetime MUST NOT be greater than the smallest TTL in the Answer section of the DNS response.  This requirement helps assure that none of the RRsets contained in a DNS response are served stale from an HTTP cache. </ins> If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from  <ins> that SOA record (see RFC2308). The stale-while-revalidate and stale-if-error Cache-Control </ins> directives (RFC5861) could be well suited to a DOH implementation when allowed by server policy.  Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer  <ins> fresh.  In such a case, the client reuses all of a cached entry, or none of it. DNS API servers also need to consider caching when generating responses that are not globally valid.  For instance, if a DNS API server customizes a response based on the client's identity, it would not want to allow global reuse of that response.  This could be accomplished through a variety of HTTP techniques such as a Cache- Control max-age of 0, or by using the Vary response header (RFC7231 Section 7.1.4) to establish a secondary cache key (RFC7234 Section 4.1). DNS API clients MUST account for the Age response header's value (RFC7234) when calculating the DNS TTL of a response.  For example, if a RRset is received with a DNS TTL of 600, but the Age header indicates that the response has been cached for 250 seconds, the remaining lifetime of the RRset is 350 seconds. DNS API clients can request an uncached copy of a response by using the "no-cache" request cache control directive (RFC7234, Section 5.2.1.4) and similar controls.  Note that some caches might not honor these directives, either due to configuration or interaction with traditional DNS caches that do not have such a mechanism. HTTP conditional requests (RFC7232) may be of limited value to DOH, as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound.  Furthermore, the HTTP response headers that enable revalidation (such as "Last-Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary RFC7541.  Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. </ins> 6.2.


4. <del> Before using a DNS API server for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a DNS API client MUST only use a DNS API server that is configured as trustworthy. A client MUST NOT use a DNS API server simply because it was discovered, or because the client was told to use the DNS API server by an untrusted party. </del>  This specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as trusted DNS API

This is similar to but, in my opinion, slightly different. The Introduction text says: I guess this implies integrity and confidentiality over the wire. For example DoH doesn't guarantee confidentiality from the DoH server learning the content of the DNS query. Ok so it's pretty clear that DoH focuses on the wire. Someone could argue it's obvious but the document actually talks about it. Then in Selection of DNS API Server the text says: And because it's a MUST, not trusting the server violates the DoH specification and hence its benefits? Patrick made the comment that trust is a client issue (URL) and I agree but there are different kinds of trust against different threats. I think we should tell clients what kind of trust they need to establish. Clients might trust the TLS connection to the server because, e.g., it uses a strong CipherSuite and they can verify the server's identity. At the same time clients might not trust the server to not profile them based on their queries and sell that information to advertisers. (In this case clients might obscure their source IP address) Clients might also not trust that the server is being diligent in checking the RRSIG records for every A record it gets from upstream servers. (In this case clients will do the DNSSEC checks themselves) In other words, clients may have a trusted connection to the server but at the same time might treat the server's application logic as untrusted. What should the client do according to the DoH document? I think the answer is they should use the server because DoH protects queries on the wire and from that aspect the server is trustworthy. But that's not clear by the current language which seems to imply absolute trust for everything. I would propose that the text is updated to say:
I am uncomfortable with this language because it implies some things about how an HTTPS resource is fetched that are defined elsewhere. Heck, with a good cache there might not even be a connection. Let's not go there. The existing text: "Before using a DNS API server for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a DNS API client MUST only use a DNS API server that is configured as trustworthy." It really tries to say the same thing twice ("in other words") - which may cause confusion. They can be blended to be: "A DNS API client selects the URI, and by extension DNS API server, used for resolution via configuration." This does remove an appropriate (imo) MUST, but the next sentence contains a MUST NOT that covers the important part. NAME wdyt?
NAME This text is much better - I support PR Only minor nit is that I might ask it says 'direct configuration' to distinguish it from any type of dynamic configuration?

4.  <ins> A DNS API client uses configuration to select the URI, and thus the DNS API server, used for resolution.  A client MUST NOT use a DNS API server simply because it was discovered, or because the client was told to use the DNS API server by an untrusted party. </ins> This specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as trusted DNS API


A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. <del> When using the POST method, the DNS query is included as the message </del>  body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents. <del> When using the GET method, the URI path MUST contain a query parameter of the form content-type=TTT and another of the form body=BBBB, where "TTT" is the media type of the format used for the body parameter, and "BBB" is the content of the body encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </del>  The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client

closes issue
I could go either way on body. You're right that the actual mime type is a bit of a problem.. I'll try it with a ct name argument without a value having the default meaning. I think that's explicit enough, while I don't really like totally implicit things like the absence of ct (what if you mis-spell it?)
NAME Actually what was the reasoning behind passing Content-Type as a query parameter instead of as the Content-Type header? Presumably any DNS API server must be able to parse headers...
Content-Type as a header refers to the message payload which isn't what we're trying to describe here.. (its used on POST, where it matches..)
NAME referring back to pull , you wrote this: "I could go either way on body. You're right that the actual mime type is a bit of a problem.. I'll try it with a name argument without a value having the default meaning. I think that's explicit enough, while I don't really like totally implicit things like the absence of (what if you mis-spell it?)" I'm fine with having now named , but I'm concerned by the use of a the query parameter without a value at all... Whilst this is probably too unwieldy: /dns-query?ct=application/dns-udpwireformat&dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB the use of alone just URL /dns-query?ct&dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB Yes, I know it's valid according to RFC 3986, but I'm wondering whether, since it's very unlikely that a JSON format would be passed using a GET, we could treat the absence of as implying ? Alternatively we could allow a couple of special values for the parameter: - implies that the format is - implies that the format is
There's a potential different approach here, use a specific parameter name for each type of query. That is, has a value that is json=...application/dns-query+json` and so on. That way you can have multiple formats on the request (for backwards compatibility). The only downside is that the backwardly compatible request will cause a hit on cache coherency, so the server might want to redirect to a canonical URL if it is concerned that the client won't consistently include both formats. (That redirect can be followed by a push if you are concerned about round trips.)
This feels cache-unfriendly to me. What is the problem with the default for ct?
It's a tiny hit to cache unfriendliness (you don't get coherency between clients that inconsistently construct requests, or you have to redirect-and-push), agreed. But it gets you the agility you wanted.
Oh, forgot to point out that this tends to be self-correcting. There are usually only a few different configurations of clients, so while those that support two request formats won't necessarily share cache hits with those that only support one, those two populations will probably happily share a cache.
NAME So to be clear, you'd allow requests like any of the following: Personally I like this - clear and neat. Maybe I'd change the parameter to (so the two options are and , but that's just me. It removes the necessity to specify the type separately and it's 'neat'. Plus extensible for future formats.
Yeah. Pick whatever colour you like for the shed, I'm not planning to live in it.
NAME describes a method that is more flexible again in . A better solution in my opinion (if you set the second half of that issue aside for the moment).
I think the color of the shed is fine for this document, and if discovery would like to do some fancy templating to enable rainbows that's fine for that separate effort.
could be much shorter. Bytes in requests matter and these are going to be used in critical conditions (early in the connection where the number of requests you can make depend on how big they are). These won't compress well enough with HPACK to get any real benefit. A short name would be an improvement. A default value for would be even better.
Could go the alt-svc approach (URL) and use two-letter combos, e.g. "ct" for , but really there out to be a standard for that approach...
I like the change to 'ct' for Content-Type, but I think 'body' is important enough where reducing it by only two bytes to 'rb' isn't worth the change. Perhaps there could be an abbreviated 'ct' value - e.g. 'ct=du'? Or, if 'ct' is not specified, then 'application/dns-udpwireformat' iMUST be assumed by the DNS server?

A DNS API Client encodes the 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 </ins> body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents.  <ins> 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 for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty. An empty value indicates the default application/dns-udpwireformat type (e.g. ct&body=...). When using the GET method the URI path MUST contain a query parameter with the name of body.  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </ins> The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client


7. <del> The data payload is the DNS on-the-wire format defined in RFC1035. The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This protocol allows DNS on-the-wire format payloads of any size. When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then provided as a variable named "dns" to the URI Template expansion.  Padding characters for base64url MUST NOT be included. When using the POST method, the data payload MUST NOT be encoded and is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. The media type is "application/dns-message". </del>  8.

paul has given this thumbs up out of band
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "special meta QTYPEs"
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "EDNS UDP Payload size cache issue"
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "TC and message size".

7.  <ins> The data payload for the application/dns-message media type is a single message of the DNS on-the-wire format defined in section 4.2.1 of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used in RFC7858 (which uses the format defined in section 4.2.2 of RFC1035). DNS API clients using this media type MAY have one or more EDNS options RFC6891 in the request.  DNS API servers using this media type MUST ignore the value given for the EDNS UDP payload size in DNS requests. When using the GET method, the data payload for this media type MUST be encoded with base64url RFC4648 and then provided as a variable named "dns" to the URI Template expansion.  Padding characters for base64url MUST NOT be included. When using the POST method, the data payload for this media type MUST NOT be encoded and is used directly as the HTTP message body. </ins> 8.


5.2. <del> For 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 JSON-based content type. The examples uses HTTP/2 formatting from RFC7540. A query for the IN A records for "www.example.com" with recursion turned on using the GET method and a wireformat request would be: </del>  The same DNS query, using the POST method would be:

proposed to close issue
NAME thanks
If it isn't then including it in an example might be unwise. Explicitly pointing out that it is currently fictitious might avoid confusion.
some typos

5.2.  <ins> These examples use HTTP/2 style formatting from RFC7540. 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. </ins> The same DNS query, using the POST method would be:


Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> In the HTTP responses, the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response.  Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </del>  A DNS API Server MUST be able to process application/dns- udpwireformat request messages.

closes issue
NAME thanks.
The draft says "the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response", which might not be strong enough. A SHOULD might be OK for shorter, but allowing the value to increase might be unwise, depending on the caching model.
agree
Seems like it should be MUST:
some typos, also, I can't seem to parse 1 of the sentence.

Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality.  <ins> 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. A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </ins> A DNS API Server MUST be able to process application/dns- udpwireformat request messages.


9. <del> 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. </del>  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.  [[ From the WG charter: The working group will analyze the security and privacy issues that

Separate out confidentiality and authentication - -01 said "Running DNS over HTTPS relies on the security of the underlying HTTP connection." This PR clarifies that the HTTPS connection can only provide confidentiality and authentication of the DNS API server. Clients wanting authentic DNS answers need to perform DNSSEC validation or explicitly trust the DNS API server.
I reverted this because my comment above was not satisfied before merge.
pr did some of this but was backed out. see that diff and discussion
I agree with the notion of separating transport security from e2e validation.. but I think the changes overshoot a touch. I would leave the first paragraph alone - https provides more than confidentiality and I don't think the text suggests anything other than doh relies on https. I like your second paragraph - though if we leave the first one in tact you probably want to remove the "also authenticates" part.. it can be recast as transport security between api server and client vs e2e validation

9.  <ins> 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. </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. <ins> 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. </ins> [[ From the WG charter: The working group will analyze the security and privacy issues that


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>  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>  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>  A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

… 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.

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  <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.  <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.  <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


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>  11.  References

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.

10.  <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


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>  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

9.  <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.  [[ From the WG charter: The working group will analyze the security and privacy issues that


(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>  A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

…
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.

(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  <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


Server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment.  11. Joe Hildebrand contributed lots of material for a different iteration

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.

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


A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over <del> HTTP. </del>  This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its

As I understand it, the referenced CORS standard (URL) is obsolete, and has been superseded by the WHATWG fetch spec (URL). Whether this is the official W3C position, I'm not clear, but the WHATWG folks certainly seem to be running with the ball.
NAME any idea on what the right thing to do here is? or NAME ?
The fetch spec is right, and referencing URL is the appropriate thing to do. This will make the IESG unhappy because fetch doesn't meet their standards for stability of reference, but they will have to learn to deal with that (there's an open discussion about this point). The other problem is that this still doesn't help provide the necessary context. Fetch is one of the most impenetrable and obtuse specifications in existence. Its description of CORS is really quite poor as an informational resource. It's only really useful to someone who already knows what it means. I'd recommend not worrying about that though. There are plenty of resources on the web that do a better job of explaining CORS.
I would rather put a link to a readable reference than an unreadable one. Thus, I propose (in all seriousness) . If the IESG doesn't want that, they can propose something better.
For an informative reference, that's probably totally appropriate. I hope that we aren't going to start specifying the details of cross-origin requests. That wouldn't be appropriate here.
I agree that the CORS portion of the fetch spec URL clear. Even the examples in the spec (most of which I wrote) don't really help much, since the entire spec is really 'aimed' at browser manufacturers rather than end-users. However, it has basically superseded the W3C spec originally referenced, and I'm fed up with seeing references to the W3C spec... It's really no big deal, but I'd prefer the link to refer to URL
W3C/IETF Liaison hat on Early signs I'm getting from W3C is that Fetch is the best thing to reference, although they're still doing some process things on making that formal. My .02 - I think asking W3C / WebAppSec formally is going to be more productive than guessing or going on aesthetics. Setting a precedent of referencing based on our preferences rather than the responsible body's is probably not something we want to do. I'm happy to facilitate a discussion with them if the need arises.
NAME when I spoke to NAME he said that getting W3C to update their CORS spec to note that it had been superseded by fetch was... unlikely. Of course, this was a while back.
I'm more optimistic now. If you think this could be improved it would help if you filed actionable feedback as issues. (FWIW, I've had some success pointing Stack Overflow questions to the official standard.)
NAME FWIW, I don't think there was any intent by anyone to disparage the work you've done on fetch. It's just that it's a standard that was documented from the POV of browser developers rather than end-users. At least, that's my take.
The "CORS protocol" section is not really meant for "browser developers" other than the "HTTP new-header syntax" section, which is normative for the header parsing requirements. Nothing else is normative there, all normative requirements are in the "Fetching" section. (It's also not for end users, but it's certainly for web developers.)

A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over  <ins> HTTP in a safe way consistent with Cross Origin Resource Sharing (CORS) CORS. </ins> This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its


freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. <del> Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </del> A DNS API Server MUST be able to process application/dns- udpwireformat request messages. This document does not change the definition of any HTTP response codes or otherwise proscribe their use.  6.1. This is an example response for a query for the IN A records for

The draft explicitly prohibits ETag, which suggests that we don't care for revalidation requests at the HTTP layer (and reliance on the resolver cache). I don't think that's necessary. Revalidation requests are a feature HTTP provides. It might be that the cost of serving revalidation is comparable to the cost of making a genuine request. DNS responses are generally modest in size. But using that as the basis of a decision here might foreclose on some use cases, for which it might be annoying to have to revise the protocol to support. Right now, I don't see a concrete reason to prohibit revalidation, ETag, Last-Modified, and the works. If we consider the DNS API server as authoritative for its view of the state of particular resource records, then all these things can be used. For instance, Last-Modified can refer to the time that the DNS API server last received a response (or even when it last received a response that changed its cached value, which is a different view on this). That said, the rough model I described in seems to suggest that DNS TTL limits what HTTP can do. If that model is correct, and both the DNS stack and API server cache right up to the TTL, then HTTP caching can't add any value.
It doesn't prohibit etag (well, at least the author wasn't trying to have it do that).. as you say, revalidation is a feature HTTP provides and its not cool for a foo over http draft to mess with that. Similar thing with 304 - 304 isn't real useful here and the draft is trying to steer you away from it in the name of quality of implementation.. but 304 is going to mean what HTTP says 304 means, doh doesn't have the hubris to change that. there is a triggering non-normative 'should' in the mix. it does try and explain that they aren't that helpful here - but I guess that's really based on the pov that the DoH Server is a gateway to traditional DNS. In that scenario, which the draft talks about, a stale resource will probably revalidate because the traditional DNS side can't revalidate. I guess you could do some kind of byte for byte comparison and use 304 as a way to extend the ttl. and of course, there is no reason the DoH server can't just plain be the terminal authoritative server and thus easily do revalidation based on something other than the DNS protocol. based on those thoughts I'll try and find a PR that downgrades this to "FYI - writing revalidation code might not be that impactful"
feedback from singapore is to change to text so that it doesn't discourage revalidation but instead explores the space a bit

freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response.  A DNS API Server MUST be able to process application/dns- udpwireformat request messages. This document does not change the definition of any HTTP response codes or otherwise proscribe their use. <ins> HTTP revalidation of cached DNS information may be of limited value as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound instead.  Furthermore, the HTTP response headers that enable revalidation (such as "Last- Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary RFC7541. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation.  DNS API servers may wish to consider whether providing these optional response headers is worthwhile. </ins> 6.1. This is an example response for a query for the IN A records for


This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its <del> content), but standardisation might make this easier to accomplish. </del>  Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of defined. The protocol must use a secure transport that meets the <del> requirements for modern HTTPS. </del>  4.1. 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 body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty. An empty value indicates the default application/dns-udpwireformat type (e.g. ct&body=...). </del>  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 encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </del>  The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client solely up to the format, and not defined in this protocol. At the time this is published, the response types are works in <del> progress.  The only known response type is "application/dns- udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del>  The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS(0) extensions, depending on the extension A DNS API Server MUST be able to process application/dns- udpwireformat request messages. <del> A DNS API Server SHOULD respond with HTTP status code 415 upon receiving a media type it is unable to process. </del>  This document does not change the definition of any HTTP response codes or otherwise proscribe their use.

minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).

This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its  <ins> content), but standardization might make this easier to accomplish. </ins> Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of defined. The protocol must use a secure transport that meets the  <ins> requirements for HTTPS. </ins> 4.1. smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter  <ins> with the name of "ct" and a value indicating the media-format used for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&body=...). </ins> When using the GET method the URI path MUST contain a query parameter  <ins> with the name of "body".  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </ins> The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client solely up to the format, and not defined in this protocol. At the time this is published, the response types are works in  <ins> progress.  The only response type defined in this document is "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS(0) extensions, depending on the extension A DNS API Server MUST be able to process application/dns- udpwireformat request messages.  <ins> A DNS API Server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to process. </ins> This document does not change the definition of any HTTP response codes or otherwise proscribe their use.


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>  7.

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.

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  <ins> record with an address of 192.0.2.1 and a TTL of 128 seconds. </ins> 7.


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>  The protocol must use a secure transport that meets the requirements for HTTPS.

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.

The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to  <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.


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 <del> 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>  A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic This document does not change the definition of any HTTP response codes or otherwise proscribe their use. <del> HTTP revalidation of cached DNS information may be of limited value as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound instead.  Furthermore, the HTTP response headers that enable revalidation (such as "Last- Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary RFC7541. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation.  DNS API servers may wish to consider whether providing these optional response headers is worthwhile. </del> 6.1. This is an example response for a query for the IN A records for 7. <del> This protocol MUST be used with https scheme URI RFC7230. </del>  7.1.  The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. The messages in classic UDP based DNS RFC1035 are inherently

There are plenty of reasons to "extend" a TTL, such as if the TTL is below a configured threshold or if one cannot reach the authoritative server again. The rules for TTLs is (again...) being actively debated in the DNSOP WG, and it would be inappropriate for DOH to be more restrictive than DNS itself, thus the "SHOULD".
Leaving a bare "SHOULD" there asks more questions than this text answers. If the considerations for extension are equivalent to those that apply to DNS, then saying that would help a lot.
I hear that, but I'm at a loss of what words to use, given that the words don't exist in the DNS specs either. What is important to me is that we don't do more than the DNS specs, as vague as they are.
If implementations routinely (or otherwise) ignore the TTL, why not then say MUST? Then it's clear what the TTL is, and now they are just ignoring the TTL (as per normal DNS practice).
Good point, will fix before pulling.
NAME can you give a review here? github apparently won't let me ask you directly because you created the PR (which I seriously amended)
The draft doesn't really tackle the question of caching fully right now. I think that there is an implied hierarchy of caches that are in use. The query first hits the DNS stack, which maintains its own cache. Using the DNS TTL, that cache might decide to answer the query. Then there is an HTTP stack, which might maintain its own cache. Notably, none of the HTTP cache-busting techniques work from the perspective of the DNS client, so we have to be careful to observe that. This particularly ordering makes much worse. Finally, a DNS API server might maintain its own cache.
worth noting that the DNS client doesn't have e2e cache busters with an http cache in the chain.. but does a traditional dns client have a cache buster? I've only really seen them explicitly ask another resolver.. which still seems possible here.
Could we add a sentence saying that the gateway decapsulating DNS-over-HTTPS MUST subtract the age of the HTTP response from the TTL inside the UDP packet before forwarding or consuming it (assuming that wouldn't break DNSSEC)? I think it would help with some of the confusion about interaction between HTTP and DNS caches.
probably worth noting HTTP "Age" and things like stale-while-revalidate to help the reader, but we want to be careful not to look like we're making changes to http when we aren't. There was also a clear call to have full caching examples that illustrate the interactions at hand. I think my read of the room in Singapore was that we don't want to encourage rewriting the DNS records. (DNSSEC being at least one reason).
I think we do want a DOH client to rewrite TTL when it is posing as a resolver to TTL-sensitive DNS clients. TTL is excluded from DNSSEC signing, so there shouldn't be a problem with that.
on caching.... we should also clarify behaviours of caching proxies. If a caching proxy starts caching based on GET parameters, we can hit an issue when the DOH backends are providing geo-targeted based on querier IP. The first query would warm the cache and the second query from a second totally unrelated subnet would get a cached answer which is not the one it would get if it were to query the DOH server directly. It may be worth having a section about potential caching caveats. see URL
NAME what are you thinking of saying that is not covered by the http rfc's? (723x).
The current document talks about how using an ID of 0 is cache friendly. Which would lead to believe that if you have a layer of caching proxies in front of the DOH servers, they could cache the content and distribute it without re-querying the DOH backend for TTL time. While this will work just fine in most cases, there is a caveat when the DOH servers return queries that are different/customized for different subnets such as with a DNS global load balancer. I am not sure if this is covered in some aspect in one of the 723X RFCs, but I think we should drop a “consideration” for people to realize when to disable caching from reverse proxies. If there is already an RFC detailing this, great let’s link to it. If not I don’t think it deserves a lot, but we should let people be aware of the potential issue.
this issue is kind of broad.. I suggest we call the base fix here, and we'll open follow on issues as necessary.
Why use SHOULD? What would cause someone to extend the TTL beyond the freshness lifetime? Hi list, Should we clarify the behaviour of caching proxies? When using a proxy in front of DOH servers and doing targeting based on resolver IP or using ECS, the returned answer for a same query (body param) may be different depending on the client, but if the caching proxy caches based on GET parameters, there is chances to return answers that are supposed to be correct for another client. In draft-ietf-doh-dns-over-https-02 Section 5: and As much as we may instruct the client to cache the result, if there is proxies in the middle, those should not cache the answer they received from backend DOH servers. Manu

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  <ins> response.  Specifically, 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 This document does not change the definition of any HTTP response codes or otherwise proscribe their use.  6.1. This is an example response for a query for the IN A records for 7.  <ins> This protocol MUST be used with the https scheme URI RFC7230. </ins> 7.1. <ins> A DOH API Client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the Cache-Control no-cache directive however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will contain the RFC7234 Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response.  DNS API clients should subtract this time from the DNS TTL if they are re-sharing the information in a non HTTP context (e.g. their own DNS cache) to determine the remaining time to live of the DNS record. HTTP revalidation (e.g. via If-None-Match request headers) of cached DNS information may be of limited value to DOH as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound.  Furthermore, the HTTP response headers that enable revalidation (such as "Last-Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary RFC7541.  Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. DNS API servers may wish to consider whether providing these validation enabling response headers is worthwhile. The stale-while-revalidate and stale-if-error cache control directives may be well suited to a DOH implementation when allowed by server policy.  Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer fresh under some extenuating circumstances defined in RFC5861. All HTTP servers, including DNS API servers, need to consider cache interaction when they generate responses that are not globally valid. For instance, if a DNS API server customized a response based on the client's identity then it would not want to globally allow reuse of that response.  This could be accomplished through a variety of HTTP techniques such as a Cache-Control max-age of 0, or perhaps by the Vary response header. 7.2. </ins> The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. The messages in classic UDP based DNS RFC1035 are inherently


5.  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>  A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods.

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.

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.  <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.


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>  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>  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

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 :)

5.  <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.  <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.  9. Running DNS over HTTPS relies on the security of the underlying HTTP


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>  empty.  An empty value indicates the default application/dns- <del> udpwireformat type (e.g. ct&body=...). </del>  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>  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>  When using the POST method, the body MUST NOT be encoded.

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.

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  <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-  <ins> udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter  <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  <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.


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>  <del> The same DNS query, using the POST method would be: </del>  6.

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.

These examples use HTTP/2 style formatting from RFC7540. These examples use a DNS API service located at  <ins> https://dnsserver.example.net/dns-query to resolve the IN A records. </ins>  <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.


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>  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>  The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS extensions, depending on the extension

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.

https://dnsserver.example.net/dns-query to resolve the IN A records. The requests are represented as application/dns-udpwirefomat typed  <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  <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


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>  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

…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 :)

smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter  <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


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.

... 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.

Abstract  This document describes how to run DNS service over HTTP using https:// URIs.


API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS.  10. Joe Hildebrand contributed lots of material for a different iteration

we can provide a reminder that http is stateless and therefore reordering happens so don't use doh for a session protocol.

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