[GH-ISSUE #2603] Aggressive NSEC caching #1027

New issue

Open

opened 2026-03-16 01:18:48 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 01:18:48 +03:00

Owner

Originally created by @divergentdave on GitHub (Nov 21, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2603

Support for aggressive NSEC caching would improve performance when handling queries that get a negative response, and reduce load on authoritative name servers, especially root name servers. (see https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf)

Implementing this would require new data structures to store NSEC or NSEC3 records in sorted order with their siblings. We may want something like moka::sync::Cache<Name, Arc<RwLock<BTreeMap<Label, ...>>>>. The values in the nested map would store the NSEC or NSEC3 record, along with the RRSIG covering it, and likely a Proof.

See RFC 8198. This builds on #2595.

Originally created by @divergentdave on GitHub (Nov 21, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2603 Support for aggressive NSEC caching would improve performance when handling queries that get a negative response, and reduce load on authoritative name servers, especially root name servers. (see https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf) Implementing this would require new data structures to store NSEC or NSEC3 records in sorted order with their siblings. We may want something like `moka::sync::Cache<Name, Arc<RwLock<BTreeMap<Label, ...>>>>`. The values in the nested map would store the NSEC or NSEC3 record, along with the RRSIG covering it, and likely a Proof. See [RFC 8198](https://www.rfc-editor.org/rfc/rfc8198). This builds on #2595.