[Feature request] Add an option to set/disable negative cache.

[skid9000]

Hello,

As a continuation of #85 is it feasible to add options to the configuration to either set the negative cache time or disable it entirely?

Having to reset the cache entirely to remove all false-negative negative cache is not really optimal...

It is an option that exist in pdns and unbound as much as I know.

If it is an option that already exist, is it possible to point where it is in the documentation?

Thanks a lot, kresd is awesome.

Best regards.

[vcunat]

We don't have a separate negative cache. The implementation would need to pass through all records in the cache and determine which would be viewed as negative (including all positive NSEC* records).

[vcunat]

We do have settings for TTL bounds (lower and upper). So adding a separate option for "negative" entries – I'd find that reasonable and not complicated.

[bolemo]

We just experienced a situation in production (ISP resolver environment):
A customer reported that he got a NXDOMAIN from one of our resolvers, while the answer from our other resolvers and authoritative servers (and public resolvers) was a CNAME.

It appeared that this resolver had cached the NXDOMAIN and I solved the problem manually by using kresctl cache clear domain.com.

A way to have a low TTL for such "negative" entries would be very useful.

[skid9000]

We do have settings for TTL bounds (lower and upper). So adding a separate option for "negative" entries – I'd find that reasonable and not complicated.

That would be perfect.

[vcunat]

Note that each domain.com has control over their TTLs, so they can tweak the upper bounds in any way they want...

[edmonds]

Note that each domain.com has control over their TTLs, so they can tweak the upper bounds in any way they want...

Not in any way they want, but subject to a sensible, preferably tunable limit enforced by the resolver ;-)

https://datatracker.ietf.org/doc/html/rfc2308#section-5

   As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic.