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

Paul Hoffman <> Sat, 12 May 2018 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BDAA128954 for <>; Sat, 12 May 2018 16:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iYO96WErMIxC for <>; Sat, 12 May 2018 16:24:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9B151241F5 for <>; Sat, 12 May 2018 16:24:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 May 2018 16:24:14 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Sat, 12 May 2018 16:24:14 -0700
From: Paul Hoffman <>
To: Miek Gieben <>
CC: DoH WG <>
Thread-Topic: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?
Thread-Index: AQHT5mEMbkO3Y2FrSECwXZLZvhlEfaQmC0KAgAcuAYA=
Date: Sat, 12 May 2018 23:24:13 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Sat, 12 May 2018 23:24:17 -0000

On May 8, 2018, at 2:45 AM, Miek Gieben <> wrote:
> I like this text, but is the working-group OK with *not* mentioning DNSSEC?
> If you only look a the TTL and not the inception and expiry dates of RRSIGs you can easily serve BAD data.

That's not how I read RFC 4033. It says:

8.1.  TTL Values vs. RRSIG Validity Period

   It is important to note the distinction between a RRset's TTL value
   and the signature validity period specified by the RRSIG RR covering
   that RRset.  DNSSEC does not change the definition or function of the
   TTL value, which is intended to maintain database coherency in
   caches.  A caching resolver purges RRsets from its cache no later
   than the end of the time period specified by the TTL fields of those
   RRsets, regardless of whether the resolver is security-aware.

   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
   the other hand, specify the time period during which the signature
   can be used to validate the covered RRset.  The signatures associated
   with signed zone data are only valid for the time period specified by
   these fields in the RRSIG RRs in question.  TTL values cannot extend
   the validity period of signed RRsets in a resolver's cache, but the
   resolver may use the time remaining before expiration of the
   signature validity period of a signed RRset as an upper bound for the
   TTL of the signed RRset and its associated RRSIG RR in the resolver's

To me, "may use the time remaining before expiration" does not sound a requirement, or even an expectation. 

--Paul Hoffman