[dns-wg] Draft of RIPE DNS Resolver Best Common Practices
- Previous message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
- Next message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Petr Špaček
pspacek at isc.org
Wed Nov 29 11:21:32 CET 2023
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
- Previous message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
- Next message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]