Re: [dnsoverhttp] Caching model

[Mark Nottingham <[e-mail]>]

> On 30 Oct 2017, at 12:36 pm, Martin Thomson <[e-mail]> wrote:
> 
> See https://github.com/paulehoffman/draft-ietf-doh-dns-over-https/issues/14
> and several others.
> 
> My request is that we agree on what the model is, then we can talk
> about the properties we can extract from that.
> 
> My understanding is that the DNS client would consult its local stack
> and that stack would use HTTP to talk to a DNS API server.

Maybe in some deployments one day, but my understanding was that immediately, the application using DOH would be making the HTTP requests itself, not using the OS. Isn't the point here to mix it in with regular HTTP traffic (where "mix" means "on the same connections")?


>  In that
> model, there are at least three caches in play: the local DNS resolver
> cache, the HTTP cache and the DNS API server cache.
> 
> If those caches are ordered as I describe, and the two DNS caches are
> driven based on the TTL, I'm struggling to find a role for the HTTP
> cache.  There are things that HTTP can do with caching that would be
> nice, but I'm not seeing any way to really access HTTP caching
> features in that architecture.

Break out of the browser -- a CDN could easily do interesting things here. Indeed, given the likely deployments here, I'd be surprised if there weren't any HTTP caching going on, in some fashion.


> It's a little unfortunate, but in that architecture it would probably
> be better to disable HTTP caching entirely.  HTTP caching has a bunch
> of features that are more flexible, but if that caching is wedged
> between two relatively inflexible caches, it won't have any
> opportunity to add value.

So, disable the client-side DNS cache and use HTTP caching. The DNS server cache isn't relevant; since it's under the control of the authority (who also controls the HTTP caches), it can be manipulated / cleared / etc. as necessary.

That model leaves you with a much more capable cache -- most modern implementations will give you request collapsing, purge / invalidation, serving stale on error, async revalidation, etc.


--
Mark Nottingham   https://www.mnot.net/