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

Matthijs Mekking <> Fri, 18 December 2020 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D5873A0AD3 for <>; Fri, 18 Dec 2020 09:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 6NfmmZvsZfg2 for <>; Fri, 18 Dec 2020 09:02:36 -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 934213A0B32 for <>; Fri, 18 Dec 2020 09:02:34 -0800 (PST)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by with ESMTPSA id qJ9DkJqZ28AynqJ9EkhUxw; Fri, 18 Dec 2020 18:02:33 +0100
References: <> <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Fri, 18 Dec 2020 18:02:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfMuHKV4r53n+j1dHKdPV/1HJPoDIODW+TNgCjoSfOjdEAMelaeJ8z4scVAw5J2mg3d6ncKTw4eLzBFmkqrjishtMACjozE1P3XFPaPVMzSBnhnzaDnv6 s7xOdboZQu3HDJ5yZ55AfY225qr1krw0bstUJQYHXfF4fuf+MvPrVtcd7sJzebwo9f9toaMfDVdEvNmcV0CmzJaXphPODkXAeykqiZwxmzGvoa+Wg5lUmIEe 32fjkQxQ0SiAZ/i+533PDBmOOOwdOjBhqjUZU6Hyox2+KtWTYBDJHU9jXXPJ8zp2
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, 18 Dec 2020 17:02:38 -0000

Hi Peter,

I reviewed the draft and it mostly looks good. Some minor comments:

1. Perhaps instead of using ".com" as an example, use ".example" (per 
RFC 2606)?

2. Shouldn't this document also update some text parts from RFC 8198?

3. About this paragraph:

    Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is
    only possible for negative (NXDOMAIN/NoData NOERROR) responses, and
    not for wildcard responses.

I think it deserves a separate section or subsection within section 4, 
and not be tucked away in the acknowledgements.

Also this should be a bit more verbose, it took me three times to 
understand what is exactly said here.

Proposed text:

    [RFC 8198] says:

        With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL
        of the NSEC/NSEC3 record and the SOA.MINIMUM field are the
        authoritative statement of how quickly a name can start working
        within a zone.

   Here, the SOA.MINIMUM field cannot be changed to "the minimum of the
   SOA.MINIMUM field and the SOA TTL" because the resolver may not have
   the SOA RRset in cache. However, if authoritative servers follow the
   updates from this document, this should not make a difference, as the
   TTL of the NSEC/NSEC3 record is already set to the minimum value.

Ralph can of course still be acknowledged for the helpful pointer.

- Matthijs

On 23-11-2020 21:16, Peter van Dijk wrote:
> Hello,
> in
> (and earlier messages in March on the same thread), people realised
> that aggressive NSEC caching might use a much longer TTL than the
> negative TTL intended by a zone operator.
> The initial idea was to correct this in an erratum to RFC 8198
> (aggressive use of NSEC/NSEC3), but Ralph Dolmans pointed out to me
> that this would not solve the wildcard case.
> I did a lightning talk on the topic at OARC 29 (
> where the
> audience feedback, as I recall it, was agreeable to my suggestion of
> 'issuing operational guidance'.
> I have since come to the conclusion that it would be better to also fix
> this in software. Hence, please find below my draft that updates one
> sentence in 4034 and the ~same sentence in 5155. As far as I can see,
> no correction to 8198 is necessary or useful.
> Any editorial comments are welcome via GitHub (link is in the draft),
> private email, or this WG list. Any functional comments on the content,
> please post them to the WG. Thank you.
> (Warren, if you feel the wording of my acknowledgement lays blame with
> you in a way that you'd rather not see immortalised in an RFC, please
> let me know!)
> Kind regards,