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

Vladimír Čunát <> Fri, 08 January 2021 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 355923A121A for <>; Fri, 8 Jan 2021 02:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.162
X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YuTp1AuNIpwg for <>; Fri, 8 Jan 2021 02:33:12 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 491AC3A1219 for <>; Fri, 8 Jan 2021 02:33:10 -0800 (PST)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by (Postfix) with ESMTPSA id 7A360142156; Fri, 8 Jan 2021 11:33:07 +0100 (CET)
To: Peter van Dijk <>,
References: <> <> <> <>
From: Vladimír Čunát <>
Message-ID: <>
Date: Fri, 08 Jan 2021 11:33:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
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: Fri, 08 Jan 2021 10:33:14 -0000

On 1/6/21 9:01 PM, Peter van Dijk wrote:
> On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote:
>>   From resolver point of view... this implies that signed *positive*
>> wildcard answers will now get cached with this shorter "negative TTL",
>> right?  These do need to deny existence of non-wildcard match, so they
>> need to contain NSEC*.
> That depends on whether a resolver caches wildcards with the TTL of the
> wildcard RRset, or of the NSECs proving that the wildcard expansion is
> valid. My suspicion is that most resolvers today do the former, and
> when they grow the 'aggressive NSEC for wildcards' feature, they'll
> take MIN(former, latter).

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).

>> 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.