[dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
Viktor Dukhovni
ietf-dane at dukhovni.org
Mon Jan 18 06:57:48 UTC 2021
TL;DR. The BCP NSEC/NSEC3 choices are IMHO:
- NSEC ; for smaller response sizes and realistic
; acceptance that the zone data is not secret
; This also facilitates aggressive negative
; caching, reducing query loads.
- NSEC3 1 0 0 - ; for zones that prefer to discourage zone-walking
; at the cost of larger DoE response packets.
- NSEC3 1 1 0 - ; for just a handful of the largest TLDs, where
; building the full NSEC3 chain is a non-trivial
; burden. Pretty much .COM, but perhaps a few more.
Three recent data points are perhaps an indication that the message
about best-practice in this space has not yet been widely assimilated
even at TLDs. [ "Leaf" zones lower down the tree have even less just
cause to enable NSEC3 opt-out. ]
In particular, the recently launched ".spa" and ".amazon" gTLDs, and
newly signed ".aero" are using NSEC3 with opt-out, and wasteful extra
hash iterations (I find the shared "salt" value somewhat "amusing"):
h01ujevptngfpnlqv5o7ljtr5mgpmmuu.aero. IN NSEC3 (
1 1 100 332539ee7f95c32a H024I3M5E7N82AKIEKRKG4JKJB4JOSH8
NS SOA RRSIG DNSKEY NSEC3PARAM )
g19djt2akj752esm388ouk6aj02qo882.spa. IN NSEC3 (
1 1 100 332539ee7f95c32a ALB20V7NTUH2AJJD7JJ7L9IG7MICR7RF
A NS SOA MX TXT SRV RRSIG DNSKEY NSEC3PARAM )
kdp5tstbb6u4p70q8e3l7ea74ksvg6lc.amazon. IN NSEC3 (
1 1 10 76a1ff9f Q2R4LHDLQ71EMMA9JVAF2IIQDEAT9JDV
NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 )
but the full zone file is (or will soon be) accessible via CZDS and
is otherwise in good measure available from other informal sources
(certificate transparency logs, zmap, ...).
To the extent that NSEC3 still makes sense for TLDs, the closest
examples to best-current-practice are .GOOG, .DEV, .PAGE, ...
25um4oo0vkc0v0tcjprl5qj82pv2e3ui.goog. IN NSEC3 (
1 0 1 8f3fee3d92a4c131 2HM8UMA28IIQ4SUBT347HQ7FII5RJVEH
NS SOA RRSIG DNSKEY NSEC3PARAM )
6n3ds9aanpq49o7cm0cdh9382a0jh2n5.dev. IN NSEC3 (
1 0 1 b7b0891083980e59 6N3MCHJEC01UPT3IR676PLEQGRVJ2UTC
NS SOA RRSIG DNSKEY NSEC3PARAM )
98cqn8pmrp6sdug39rvmhse4cg61linm.page. IN NSEC3 (
1 0 1 b335b7536f34f743 98CUIOFUAMGOBON90HPNK6HJTVM42OBQ
NS SOA RRSIG DNSKEY NSEC3PARAM )
where there's no opt-out, and just one extra SHA1 iteration (though zero
IMHO is just as effective and cheaper). The non-empty salt is
pointless, but basically harmless.
For the largest extant TLDs, which are not yet ready to abandon opt-out,
the BCP examples are .COM and .NET where NSEC3 is used exclusively for
the "opt-out" support, (empty salt, 0 extra iterations):
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. IN NSEC3 (
1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
NS SOA RRSIG DNSKEY NSEC3PARAM )
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. IN NSEC3 (
1 1 0 - A1RUUFFJKCT2Q54P78F8EJGJ8JBK7I8B
NS SOA RRSIG DNSKEY NSEC3PARAM )
But for new gTLDs, I'd argue that they're far from likely to get
anywhere near the size of .NET any time soon (or ever), and that
"opt-out" is entirely the wrong tradeoff.
The storage cost of listing every domain in the NSEC3 chain for a
typical-size TLD (pretty much all except .COM) is modest, and there's no
reason to sacrifice denial of existence security for little to no gain.
Similarly, the 100 iterations just slow down the authoritative servers
and validating resolvers for no good reason.
I'd like to encourage the operators of TLD zones to use either
simply NSEC (IIRC .ORG have indicated intent to move to NSEC),
or where modest zone-walking protection is deemed appropriate,
use NSEC3 with no opt-out, no salt, and no extra iterations.
Just the first (implicit) SHA1 iteration is quite enough to
discourage most zone-walkers, and the zone content of TLDs
is far from secret. Even where zone feeds are not generally
available, I am typically able to obtain 75-90% of the names
in a TLD zone from other sources, without resorting to any
zone walks.
--
Viktor.
More information about the dns-operations
mailing list