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

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