Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

Peter van Dijk <> Wed, 13 January 2021 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E2373A0B37 for <>; Wed, 13 Jan 2021 01:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S6qsz914JCCp for <>; Wed, 13 Jan 2021 01:21:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8672A3A0AD8 for <>; Wed, 13 Jan 2021 01:21:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 1E8046A279; Wed, 13 Jan 2021 10:21:25 +0100 (CET)
Received: from plato ([]) by with ESMTPSA id Mhh5BpW7/l/gGwAA3c6Kzw (envelope-from <>); Wed, 13 Jan 2021 10:21:25 +0100
Message-ID: <>
From: Peter van Dijk <>
Date: Wed, 13 Jan 2021 10:21:24 +0100
In-Reply-To: <>
References: <> <> <> <> <>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2021 09:21:38 -0000

On Fri, 2021-01-08 at 11:33 +0100, Vladimír Čunát wrote:
> Well, if the client requests the proof (+dnssec), you have to include 
> those NSEC*s and I'd consider it incorrect to prolong their TTL.  I'd be 
> surprised if someone chose that lack of +dnssec could change this TTL 
> behavior, except for implementations without DNSSEC support.  At least 
> that's _my_ understanding of the current RFCs (even before 
> DNSSEC-aggressive caching).

Ah yes, now I get it. The impact of NSEC TTL on wildcard validity is
not really something that 8198 did, or that this document does. This
document does, of course, change that TTL for some setups.

> > > Maybe the final text would better explicitly note such implications, but
> > > that certainly can wait way past WG adoption. Also it might be confusing
> > > that just by singing a zone the effective TTL of these answers would get
> > > lower - assuming I got your intention right (if not, perhaps the current
> > > text wasn't clear enough anyway).
> > Whether signing a zone lowers the TTL on an expanded wildcard depends entirely on the implementation - basically my previous paragraph in this email. I'd say the right approach is the MIN(..) from the previous paragraph.
> > 
> > However, I'm unsure what text the document should have about this. As in my response to Matthijs, the problem flows from 8198 but the problem is not in 8198. That said, we can always put more explanations in this document - perhaps even a Background section, and then I can shorten the Introduction section to only explain the core of the problem.
> I had in mind adding a simple note about this (possible?) consequence, 
> as I don't think it's completely obvious and it wasn't happening before 
> implementing this RFC.

It took me a while to understand the question, but now that I get it, I
have found that at least one validator implementation does not
currently cap the TTL of expanded wildcards to the lowest TTL in the
proof. Now I wonder if that needs to be written down explicitly, and
whether that should also go into this document (which we would then
retitle 'NSEC(3) TTL clarifications'?).

Kind regards,
Peter van Dijk