[dns-operations] nsec vs nsec3 use

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Apr 13 16:40:08 UTC 2021


On Tue, Apr 13, 2021 at 09:58:16AM -0600, Grant Taylor via dns-operations wrote:

> On 4/12/21 7:51 PM, Viktor Dukhovni wrote:
>
> > my advice is to use NSEC unless you have an absolutely compelling 
> > case to attempt to deter zone enumeration
> 
> Would you please elaborate on why that is your opinion / advice?

    - Most zones have no secrets, often just the zone apex and a couple
      of common labels, "www", "smtp", "mx1", ...

    - Names from zone files leak into CT logs, mailing lists, ...
      If you actually want to keep a secret, don't publish it via DNS!

    - NSEC responses are more compact, typically needing at most two
      signed records in the response, as opposed to three NSEC3.

    - With NSEC you benefit from aggressive negative caching reducing
      query load on your authoritative server.

    - If, on the other hand, you *really* care about keeping part of
      the zone confidential, and dynamic signing is an option, then NSEC
      is great for that, with a single NODATA record created on the fly
      sufficient to deny the existence of the requested RRSet.  This is
      used by Cloudflare:

        bogusname.cloudflare.com. IN A ? ; NoError AD=1
        cloudflare.com. IN SOA (
            ns3.cloudflare.com. dns at cloudflare.com.
            2036904638 10000 2400 604800 300 )
        cloudflare.com. IN RRSIG (
            SOA 13 2 300 20210414173321 20210412153321 34505 cloudflare.com.
            AEFzUMJqAWtS/RbemGnDgLUDgWtpm6qoag/MwDCKCf84jBwVckgYfOhArSwisX2ewqRbQkFMFfmLnpnxGPB7dA== )
        bogusname.cloudflare.com. IN NSEC \000.bogusname.cloudflare.com. RRSIG NSEC
        bogusname.cloudflare.com. IN RRSIG (
            NSEC 13 3 300 20210414173321 20210412153321 34505 cloudflare.com.
            E5K51Q+/FJG60DhFCc084MglrBLeXiKYislJNxSbl85/yn2ICID8wvknbJ/irUYEggbd7EWCSOKZDOlboyC9IQ== )

> It seems contrary to the litmus test of which is more secure vs 
> difficult to implement.

You're using the phrase "more secure" in a way I am not familiar with.
I don't think of Either NSEC or NSEC3 as "more secure".  NSEC3 was
primarily designed for "opt-out", which actually deliberately reduces
security in order to gain a more compact zone with fewer records to
sign.  If, as should be the case for most zones, you don't use opt-out,
you mostly don't need NSEC3.  While discouraging casual zone walking is
also a feature of NSEC3, this is a secondary benefit, that is oversold.

It is fine to choose NSEC3 (with a low iteration count, see below), but
often not particularly beneficial.

> I'm trying to understand your thought process and subsequently make a
> more informed decision myself.

See also:

    https://mail.sys4.de/pipermail/dane-users/2021-March/000594.html
    https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-nsec3-guidance-02

-- 
    Viktor.



More information about the dns-operations mailing list