[dns-wg] Draft of RIPE DNS Resolver Best Common Practices

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