Draft: draft-ietf-doh-dns-over-https-latest

Commentary: The draft explicitly prohibits ETag , which suggests that we do n't care for revalidation requests at the HTTP layer ( and reliance on the resolver cache ) . I do n'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 do n'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 ca n't add any value . 
 It does n't prohibit etag ( well , at least the author was n'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 is n'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 does n't have the hubris to change that . there is a triggering non - normative ' should ' in the mix . it does try and explain that they are n'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 ca n'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 ca n'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 does n't discourage revalidation but instead explores the space a bit
Paragraph (version A):
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.
Paragraph (version B):
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.