[GH-ISSUE #488] Add more comprehensive tests for negative response caching #499

New issue

Open

opened 2026-03-15 22:49:38 +03:00 by kerem · 1 comment

kerem commented

2026-03-15 22:49:38 +03:00

Owner

Originally created by @briansmith on GitHub (May 24, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/488

Let's make sure we have test cases for the various scenarios described in the RFCs (https://tools.ietf.org/html/rfc2308 and various updates; see also https://tools.ietf.org/html/rfc1912#section-2.2). In particular, @bluejekyll noted:

The LookupState::handle_nxdomain handles searching for this, but only if the upstream server/Resolver is properly sending the SOA record.

In general, most products probably want to err on the side of querying too frequently instead of less frequently, when there's no indication of how long to cache a negative response.

Originally created by @briansmith on GitHub (May 24, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/488 Let's make sure we have test cases for the various scenarios described in the RFCs (https://tools.ietf.org/html/rfc2308 and various updates; see also https://tools.ietf.org/html/rfc1912#section-2.2). In particular, @bluejekyll noted: > The LookupState::handle_nxdomain handles searching for this, but only if the upstream server/Resolver is properly sending the SOA record. In general, most products probably want to err on the side of querying too frequently instead of less frequently, when there's no indication of how long to cache a negative response.

kerem added the

crate:resolver

label

2026-03-15 22:49:38 +03:00

kerem commented

2026-03-15 22:49:49 +03:00

Author

Owner

@briansmith commented on GitHub (May 24, 2018):

@bluejekyll also suggested:

We can file an issue for adding a heuristic that would start with the minimum and then increase to either the max or SOA setting on successive failure. That’s not something needed in this change though.

That sounds like a good idea. we could start at the minimum TTL and then double to the maximum, or something. Maybe we should probably validate that that behavior is wanted by multiple things before we bother adding that complexity.

@briansmith commented on GitHub (May 24, 2018): @bluejekyll also suggested: > We can file an issue for adding a heuristic that would start with the minimum and then increase to either the max or SOA setting on successive failure. That’s not something needed in this change though. That sounds like a good idea. we could start at the minimum TTL and then double to the maximum, or something. Maybe we should probably validate that that behavior is wanted by multiple things before we bother adding that complexity.

kerem referenced this issue

2026-03-15 22:50:50 +03:00

[GH-ISSUE #499] Add SOA resolution for any name #504