Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

Francis Dupont <> Wed, 19 July 2017 09:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E6961317AD for <>; Wed, 19 Jul 2017 02:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJhrDnjtlpjw for <>; Wed, 19 Jul 2017 02:07:22 -0700 (PDT)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C095912ECC0 for <>; Wed, 19 Jul 2017 02:07:21 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id v6J8ol1c028029; Wed, 19 Jul 2017 10:50:47 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Mukund Sivaraman <>
In-reply-to: Your message of Tue, 18 Jul 2017 17:27:39 +0530. <20170718115739.GA32524@jurassic>
Date: Wed, 19 Jul 2017 10:50:47 +0200
Archived-At: <>
Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 09:07:23 -0000

 In your previous mail you wrote:

>  NSEC needs no keys, only their RRSIGs would which wouldn't exist in
>  unsigned zones. In this case the unsigned NSEC would also not be part of
>  the zone (it would have to be synthesized and maintained outside the
>  zone).

=> but it is created by an authoritative server, isn't it?
And as it is synthesized I can't see a good reason to use NSEC3 instead.

>  Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix
>  entire zones, when it was discussed, Mark Andrews suggested that
>  requiring DNS COOKIE to further reduce the chance of cache poisoning
>  (more than source port randomization and random message ID) could be a
>  reasonable idea to think about.

=> it adds a nonce so another (short) bunch of unpredictable bits.
As NSEC is not signed it is more than vulnerable to on-the-path attacks.
I am afraid it is first a massive zone destruction weapon and after
perhaps an optimization...

>  > It seems easier to remember that DNSSEC offers proofs for denial of
>  > existence.

=> still applies...


PS: really if this is deployed I can see more "interesting" ways for misuses
than real benefits. Of course it can be a mean to make zone managers
to rush on DNSSEC...