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

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