Re: [dnsoverhttp] Caching model

Mark Nottingham <mnot@mnot.net> Mon, 30 October 2017 05:00 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF6513FD8F for <dnsoverhttp@ietfa.amsl.com>; Sun, 29 Oct 2017 22:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=er1DlSXs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LBTzGQyl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeVzz8qYAtf9 for <dnsoverhttp@ietfa.amsl.com>; Sun, 29 Oct 2017 22:00:04 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5598C13F491 for <dnsoverhttp@ietf.org>; Sun, 29 Oct 2017 22:00:04 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AD9FD20A23; Mon, 30 Oct 2017 01:00:03 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 30 Oct 2017 01:00:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=FieStg6fK8hsCu/7kPzFg8xGap72L 8RaM+qh0LCNoBg=; b=er1DlSXse7kkASYODNzqfaxe3BQeVII7nvs01vkMzQgRc nCrkQUhMyFZUwg/6l07WXB5d1FS5J08H7M+XDYw0+zrxIHxk27PL9wVYMo94FZ+E lsdFug7KSKG3B3qp7QPdBqXJE9EuLj/pejoTncW0ti0QLcfT/h4xI5JJegtRR2lL ov8EbgJfn4U+sGJaWdwLqsKRYCtMlEBXB8xhTAI2nZ5kEX6bdaIc4imVxOAcxoPF IODc8zQXhG0R3SXOR1qcD6MFa+lAEfVV0HaSmu/fubizKSdWbjAcp6ePk72vIUJD LElmE+5cZuFuZKYW9TbbcQ4Txb4px1ze7FLo2L08w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FieStg 6fK8hsCu/7kPzFg8xGap72L8RaM+qh0LCNoBg=; b=LBTzGQyl5JHWaumc5UMJhq B4cWz6qbt47HdqXquYLHrpnjNTyThtoTSK6HsfA0U86EOdcnx7jlecsJlpvyWkoC yAiS70kA/xu5d54w7/CIlYPNBZ4uAxHK4Ma6mYghDJfTOpalHCTBNFrmT1MxQ0Kw oXIuu0pyqO8fq+8yrD4DOj47cOTvUi0E48NX7G2vCgysITMFRR2aVSEiwiA3o62o K1RvNaxaY49DZz9MHQK0FSO29vhZvzF79FUt2AEfb64BuSbLhn0XGTwGfVTNqLvK zwgATzVTDDFG4WbKCwlOc3hiPQWEb16/Vmko6OkSlHRtrLC4H8s/abPP1IZ/n8IQ ==
X-ME-Sender: <xms:07H2WX-j9MoGFvpBU_YclJdGR5Av8KuEIHf7SdGXtMiyQlVmhnH4gA>
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A8F0242CF; Mon, 30 Oct 2017 01:00:01 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CABkgnnU_5Q6BOxf+HzpuCSkb8OG5i0sgqyF9UEr9VRyDvd5s7w@mail.gmail.com>
Date: Mon, 30 Oct 2017 15:59:58 +1100
Cc: dnsoverhttp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DEF35BA-08E7-417B-994C-7F000257E268@mnot.net>
References: <CABkgnnU_5Q6BOxf+HzpuCSkb8OG5i0sgqyF9UEr9VRyDvd5s7w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/_D-SWAi3FSKANTj9kEIEAU-Nng4>
Subject: Re: [dnsoverhttp] Caching model
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 05:00:06 -0000


> On 30 Oct 2017, at 12:36 pm, Martin Thomson <martin.thomson@gmail.com> 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/