[. If your domain is DNSSEC signed and employs NSEC3 for authenticated
denial of existence, or you're considering deploying DNSSEC at some
point, read on... ]
RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size
up to perhaps as high as 2500 iterations for 4096-bit keys. In
retrospect such a generous iteration cap is counter-productive. It is
neither particularly effective at keeping your zone content "secret",
nor sufficiently cheap to avoid negative impact on authoritative and
iterative resolver performance.
In that light, Wes Hardaker and I have authored an Internet-Draft that
strongly recommends setting the NSEC3 additional iteration count to 0
(at least one initial SHA1 hash is always performed).
https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02
Today, the Knot resolver became the first one to cap NSEC3 iterations
for now at 150, but this will likely be reduced further (perhaps
ultimately as low as ~25):
https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1
and is expected to be done by more resolvers.
Since iteration counts above the resolver cap make denial-of-existence
for the entire zone insecure, it is important that all domains with a
high NSEC3 iteration count proactively lower it ideally to 0, but
otherwise ~10 or less.
While DNSSEC still precludes forged positive answers, any signed
NXDomain or NODATA NSEC3 response can be replayed for any query,
regardless of the qname.
This impacts any protocol in which negative responses have security
consequences. Potential exposures include:
- Forged absence of RFC7672 DANE SMTP TLSA records
- Forged absence of CAA records
- Forged absence of HTTPS records enabling various downgrades
- ...
A number of TLDs have already lowred their iteration counts, and it is
expected that most of the rest will follow soon.
TLD before after
--- ------ -----
la 150 1
xn--q7ce6a 150 1
blue 100 10
green 100 10
lat 100 10
mx 100 10
pink 100 10
red 100 10
schaeffler 100 10
by 100 3
creditunion 100 3
ally 100 1
autos 100 1
boats 100 1
homes 100 1
motorcycles 100 1
yachts 100 1
If your DNS zone is configured to use NSEC3, please:
- Reduce the iteration count to 10 or less.
- Disable opt-out, you're very unlikely to need it.
- Either rotate the salt each time you sign, or skip
it entirely. But a short fixed salt is harmless if
leaving it alone easier than changing it.
Of course, if your zone is small enough (just the zone apex and a
handful of already public or easy to guess names) or in any case has
nothing to hide, even better is to use just plain NSEC. You get smaller
negative replies (less exposure to DoS) and more effective negative
caching at resolvers. So in many cases, it is even simpler to abandon
NSEC3 entirely. Please also consider the pros/cons of that option.
--
Viktor.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
denial of existence, or you're considering deploying DNSSEC at some
point, read on... ]
RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size
up to perhaps as high as 2500 iterations for 4096-bit keys. In
retrospect such a generous iteration cap is counter-productive. It is
neither particularly effective at keeping your zone content "secret",
nor sufficiently cheap to avoid negative impact on authoritative and
iterative resolver performance.
In that light, Wes Hardaker and I have authored an Internet-Draft that
strongly recommends setting the NSEC3 additional iteration count to 0
(at least one initial SHA1 hash is always performed).
https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02
Today, the Knot resolver became the first one to cap NSEC3 iterations
for now at 150, but this will likely be reduced further (perhaps
ultimately as low as ~25):
https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1
and is expected to be done by more resolvers.
Since iteration counts above the resolver cap make denial-of-existence
for the entire zone insecure, it is important that all domains with a
high NSEC3 iteration count proactively lower it ideally to 0, but
otherwise ~10 or less.
While DNSSEC still precludes forged positive answers, any signed
NXDomain or NODATA NSEC3 response can be replayed for any query,
regardless of the qname.
This impacts any protocol in which negative responses have security
consequences. Potential exposures include:
- Forged absence of RFC7672 DANE SMTP TLSA records
- Forged absence of CAA records
- Forged absence of HTTPS records enabling various downgrades
- ...
A number of TLDs have already lowred their iteration counts, and it is
expected that most of the rest will follow soon.
TLD before after
--- ------ -----
la 150 1
xn--q7ce6a 150 1
blue 100 10
green 100 10
lat 100 10
mx 100 10
pink 100 10
red 100 10
schaeffler 100 10
by 100 3
creditunion 100 3
ally 100 1
autos 100 1
boats 100 1
homes 100 1
motorcycles 100 1
yachts 100 1
If your DNS zone is configured to use NSEC3, please:
- Reduce the iteration count to 10 or less.
- Disable opt-out, you're very unlikely to need it.
- Either rotate the salt each time you sign, or skip
it entirely. But a short fixed salt is harmless if
leaving it alone easier than changing it.
Of course, if your zone is small enough (just the zone apex and a
handful of already public or easy to guess names) or in any case has
nothing to hide, even better is to use just plain NSEC. You get smaller
negative replies (less exposure to DoS) and more effective negative
caching at resolvers. So in many cases, it is even simpler to abandon
NSEC3 entirely. Please also consider the pros/cons of that option.
--
Viktor.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/