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

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