Moin! On 26 Nov 2023, at 18:01, Shane Kerr 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.
### DNS Cookies
**Interoperable DNS Cookies should be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
Same as above may instead of should. While it theoretically might seem like a good idea, the practical deployed implementations have shown its not: https://casey.byu.edu/papers/2021_pam_dns_cookies.pdf
### Filtering and blocking
#### Legal blocking: **Legal requests and blocking and filtering laws:** DNS resolvers should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services.
There are cases where this is not possible, eg. the law forbids it. We should IMHO at least acknowledge that.
#### RPZ-based filtering
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms) using RPZ. This allows updates to occur very quickly. These source must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz](https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
RPZ is just one mechanism to do this. It has nothing to do with the actual content. Shouldn’t we generalise that requirement and just talk about blocklists and not the mechanism? Overall the document is an extensive well written overview of the DNS resolver problem space and I would like to thank the members of the RIPE DNS Resolver BCP Task Force for all of their hard work on this. So long -Ralf --- Ralf Weber