[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