Feature request: Separate NXDOMAIN cache with its own max-ncache-size
This relates to PRSD DDoS attacks, and the effect on participating resolvers when the domain under onslaught is able to keep responding and does not die or rate-limit the resolvers.
The scenario is one in which a very large number of unique names are being queried, the objective being to bypass cached NXDOMAINs in resolvers and to force every name to become a query to the authoritative servers for the domain (or hosting provider) that is being attacked.
Typically, the target servers will either die, or will commence rate-limiting their perceived attackers. In the case of a resolver, this will result in a large number of recursive queries being backlogged while they wait for the server responses that never arrive.
BIND uses fetch-limits to mitigate the non-responding servers scenario.
But in the situation where the servers never die or never rate-limit, the outcome is rather different. Resolvers that can cope with the increase in traffic (which usually isn't actually that much), instead see a rapid increase in memory consumption (and decrease in cache hits!) due to the NXDOMAIN responses that are received and then cached (never to be used again).
One mitigation for resolver operators has been to reduce max-ncache-ttl to silly small values - but the effectiveness of this depends on the structure of the cache nodes and how often opportunistic cache cleaning hits these nodes.
Yes, overmem (LRU-based logic) cache-cleaning will help with this, but for many, it is going to be at the expense of 'positive' cache content, and regular clients will start to suffer with more cache-misses, as well as cache churn increasing as negative and positive cache content keeps being 'swapped'.
Mark suggested keeping negative answers in a separate cache, where they could have their own max-ncache-size and churn all by themselves, without affecting main cache.
This sounds like A Good Idea - but one that we've never get got around to, as part of ongoing DDoS mitigation work.
(Also tagging this as 'Customer' since I can find many a customer ticket where customers have been bitten by this when one specific and well-known DNS hosting company have been under attack, and their servers never falter in sending back NXDOMAIN responses to their 'attackers').