Re: [dnsoverhttp] Caching model

Patrick McManus <> Tue, 31 October 2017 06:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D04DFB77 for <>; Mon, 30 Oct 2017 23:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yK0JGbgNW41q for <>; Mon, 30 Oct 2017 23:28:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 37F0713F5DE for <>; Mon, 30 Oct 2017 23:28:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id F325E3A2A1 for <>; Tue, 31 Oct 2017 02:28:42 -0400 (EDT)
Received: by with SMTP id 90so17653382lfs.13 for <>; Mon, 30 Oct 2017 23:28:42 -0700 (PDT)
X-Gm-Message-State: AMCzsaW/5LnArUzpqBncvcKN/1/KxzNaQEglE4l0dnv5aRDSosmidYA8 VDjH0DHwxbDNlWJxkjWuutHTWq3tdFkGwGZBxgE=
X-Google-Smtp-Source: ABhQp+S7BVA/Bg/JAFVWnPsfwfVe/DLgX82gX/q6q6Lai+w4EpnS2U2s9SNWTRFyVWL8HL1DcQeAL7o6yainzKksoNE=
X-Received: by with SMTP id f20mr414547lja.189.1509431321654; Mon, 30 Oct 2017 23:28:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 30 Oct 2017 23:28:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Tue, 31 Oct 2017 02:28:40 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="089e0823e0b4bd7b91055cd1dd9b"
Archived-At: <>
Subject: Re: [dnsoverhttp] Caching model
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of DNS over HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Oct 2017 06:28:48 -0000

I think the HTTP cache fundamentally plays a role as a shared cache between
multiple clients. Mark draws that picture with a CDN, which is one
possibility. Another is the javascript use case where the client DNS cache
may not exist or even if it does exist the shared cache plays the role of
heirarchical cache.. to whatever extent different first parties can share
http cache entries they can share doh entries.

in the case where this is a straight line, then it makes sense to disable
one of the two client side caches.. note that its common to have a http
cache that also stores a bunch of post-processed stuff linked to the http
cache entry.. firefox has done/does/will do that with a bunch of things
already (raster formats, javascript parsing, wasm ..) and some kind of
parsed dns record that allowed disabling the standalone dns cache would
seem likely.

On Sunday, October 29, 2017, Martin Thomson <>

> See
> 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.  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.
> 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.
> _______________________________________________
> dnsoverhttp mailing list
> <javascript:;>