On 27. 11. 23 13:16, Ralf Weber wrote:
### Aggressive NSEC caching
**Aggressive NSEC caching should be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and
NSEC3 values, can reduce traffic greatly. It is important to protect
against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3
records cover a range of names in a zone. A resolver can know that a
query falls within such a range without sending any further queries,
by remembering the NSEC or NSEC3 redords that is has seen as answers
to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling
this is less important for DNS resolver operators who have a close
relationship with users, since they can stop attacks by blocking users
or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes
negative caching in detail.
So I would disagree with this section for a couple of reasons.
First not all resolver software might have the data structures to
allow that. Second it becomes more and more obsolete with authorities
doing DNSSEC black and white lies meaning the send the minimal
covering NSEC. And given that especially providers with large
domain portfolios do that the odds of finding a DNSSEC based domain
where this actually would are low.
So I would downgrade that to a “may” and also lighten the language
a bit as there afaik have been no incidents where it actually helped.
I disagree with this disagreement :-)
From my point of view, fact that not all implementations have it is not
a good reason to change the advice "If you have it enable it."
This document says in preambule that it's not a compliance checklist, so
I don't see a trouble.
Even if every large hoster was doing DNSSEC-lies, it still tremendously
helps to limit nonsense sent to root/TLD/arpa level and basically
provides local-root-like behavior without the overhead and risks of root
zone XFR/validation/related monitoring.
I have witnessed attacks where it actually helped to keep performance at
reasonable levels while under PRSD. The trouble is that attacker quickly
realizes that it's not working _for him_ and moves to another target, so
of it does not make it into the news :-)
--
Petr Špaček
Internet Systems Consortium
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/dns-wg
