Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?

Patrick McManus <> Tue, 08 May 2018 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1FF312E891 for <>; Tue, 8 May 2018 09:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rVgvfm2-sppA for <>; Tue, 8 May 2018 09:25:21 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id 5A7ED12E9D9 for <>; Tue, 8 May 2018 09:25:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id E39423A026 for <>; Tue, 8 May 2018 12:25:20 -0400 (EDT)
Received: by with SMTP id t27-v6so28856562oij.9 for <>; Tue, 08 May 2018 09:25:20 -0700 (PDT)
X-Gm-Message-State: ALQs6tAd9+MCb7jRso+LOp43oJT6m8OoObNoXwFyHAls85O/ypKfGXgq Tdy8mPpAN6HccSNsoWVzNanCtMqboraCA1QFtIE=
X-Google-Smtp-Source: AB8JxZpgp0OxxM3hx0/vBZLO5f1lNtoQauaMbCwoj2Tcewkro8hhkgHWZLAq54bhhJ2rwUZ/O4SSfiVfSIBf64WZpfI=
X-Received: by 2002:aca:f388:: with SMTP id r130-v6mr25388281oih.17.1525796720621; Tue, 08 May 2018 09:25:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 May 2018 09:25:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Patrick McManus <>
Date: Tue, 8 May 2018 18:25:20 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Mark Nottingham <>
Cc: Patrick McManus <>, Paul Hoffman <>, DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000883e87056bb43b80"
Archived-At: <>
Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 May 2018 16:25:24 -0000

On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham <> wrote:

> > This text reads more fluidly, and that is nice. OTOH it doesn't do much
> to resolve the core tension in
> -ietf-doh-dns-over-https/issues/153. The current ID uses normative
> language for creating http freshness lifetimes from DNS sets.
> Well, Paul asked for text...
> I forgot to say thank you for the text - I just was trying to communicate
that I think the rationale is more of the blocker for this issue than the
text. So that's what I'm trying to drill down on here..

> > Comments from you and Martin (and this text suggestion) support changing
> this from normative language to advice. The other comments favor the more
> deterministic behavior we currently have.
> >
> > Can you help me understand the argument you are making? Martin primarily
> suggests having the DNS code check the TTL before use rather than relying
> on the cache to serve fresh responses - but I think that particular point
> has met significant pushback largely from the DNS experts in the community.
> I'm not hearing pushback to this approach on this thread so far, so I'd
> like to hear (here) what the issue is.

Ben and Dave pushed back in the github - it would be helpful to hear them
here as well, I agree.

> HTTP caches can and do serve stale content even without those "fancy"
> things (e.g., when the origin server is disconnected). If you're using HTTP
> and caching has taken place, you fundamentally need to understand how old
> the response you're using is if it's time-sensitive -- which this is. That
> means checking the Age.
This text doesn't prevent you from serving anything - it just defines how
you set the freshness lifetime so that an Age calculation at the HTTP level
actually reflects the fresh/stale status of the DNS content in a
conservative fashion. A client very concerned about that could make the
calculation or it can assume that the server did the best it could do (i.e.
its either fresh, or stale in extremis so use it anyhow) and use it once
for record types like A.

> The existing draft seems to have caused a little bit of confusion by
> saying SHOULD match rather than MUST match.. The intent for that was to
> allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if
> you cannot figure out the DNS lifetime from your HTTP server code). The
> subsequent sentence enforced the >= property.
> >
> > Is there another aspect to the question I'm missing?
> It looks like you're using RFC2119 requirements to bring attention to
> important parts of the specification ("we really mean that this could trip
> you up"), rather than stating actual requirements for interoperability.
> These MUSTs aren't testable, and they may be too confining in some
> deployments. This stuff really is advice, of the "if it hurts, don't do
> that" sort -- not requirements.
I must be misunderstanding what you mean by not testable - the alignment of
expiration information seems pretty observable. And there is an operational
impact to terminal clients without caches (either DNS or HTTP) which simply
want to lookup a record and use it having to retry to get non-expired info
(and the rather large risk of them not trying and using old data instead).
So I guess you can argue that without 2119 language the DOH client and
server can communicate, but without normative provisions constraining the
server you can't interop well with the Internet.. seems 2119 in scope to me.