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