Original text:
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

Reviewer comments:
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

Revised text:
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