Re: [Doh] meta qtypes

[Miek Gieben <[e-mail]>]

[ Quoting <[e-mail]> in "Re: [Doh] meta qtypes..." ]
>we need to be careful about recommending a blind tunnel (aspect) of using
>HTTP by just disabling caches. That's not really great and doesn't meet the
>DoH goals - HTTP has a rich language to control caching at its level which
>I think can be well aligned with the DNS TTL architecture (and if no-cache
>plays a role for some small part, that's fine.). There is document text
>that already tries to discuss that in Section 6. Hopefully we can revise
>that if necessary.
>
>The text already contains a normative MUST NOT about using a http freshness
>lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH
>server that cannot figure this out can comply with a freshness lifetime of
>0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel.
>
>Please note the draft uses language about freshness lifetime instead of
>normatively referencing cache-control for a reason (cc is used in "such as"
>and in an example). There are a number of ways in HTTP to express this
>concept and you want to be compatible with the existing definitions.
>
>Perhaps it just needs an additional para indicating a response bearing a
>negative answer needs a more pessimal algorithm (e.g. either not cachable
>or the SOA approach)?

I think it should. I really wish we could point to one DNS RFC that tells 
implementers on how to determine the cache TTL, but afaik that does not exist.

So, yes, either new text in this I-D or referencing a whole slew of DNS RFCs 
that say things about TTL in relation to caching.

/Miek

--
Miek Gieben