[GH-ISSUE #3119] Repetitive queries in DnssecClient #1135

New issue

Open

opened 2026-03-16 01:42:11 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:42:11 +03:00

Owner

Originally created by @divergentdave on GitHub (Jul 14, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3119

DnssecDnsHandle may make multiple concurrent identical requests for DNSKEY or DS RRsets during validation. This is not a problem for the recursive name server, as it uses a RecursorPool at lower levels, which deduplicates concurrent requests, along with a response cache for recent queries. DnssecClient does not have any deduplication or caching features, so it may send duplicate requests to its configured resolver. DnssecClient wraps a DnssecDnsHandle<Client>, and the Client wraps the DnsExchange which performs network communications.

On the other hand, the client integration tests in dnssec_client_handle_tests.rs do not directly use DnssecClient, but instead construct a DnssecDnsHandle<MemoizeClientHandle<Client>> through multiple steps. The MemoizeClientHandle wrapper includes an active_requests data structure to deduplicate concurrent requests, similar to RecursorPool. In the case of MemoizeClientHandle, it never removes entries from its data structure, so it doubles as a cache with infinite TTL as well. MemoizeClientHandle is publicly exported, and otherwise only used in tests.

Deduplication and caching features should be added to DnssecClient, to bring it to parity with the recursor, and avoid wasted network traffic.

Originally created by @divergentdave on GitHub (Jul 14, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3119 `DnssecDnsHandle` may make multiple concurrent identical requests for `DNSKEY` or `DS` RRsets during validation. This is not a problem for the recursive name server, as it uses a `RecursorPool` at lower levels, which deduplicates concurrent requests, along with a response cache for recent queries. `DnssecClient` does not have any deduplication or caching features, so it may send duplicate requests to its configured resolver. `DnssecClient` wraps a `DnssecDnsHandle<Client>`, and the `Client` wraps the `DnsExchange` which performs network communications. On the other hand, the client integration tests in `dnssec_client_handle_tests.rs` do not directly use `DnssecClient`, but instead construct a `DnssecDnsHandle<MemoizeClientHandle<Client>>` through multiple steps. The `MemoizeClientHandle` wrapper includes an `active_requests` data structure to deduplicate concurrent requests, similar to `RecursorPool`. In the case of `MemoizeClientHandle`, it never removes entries from its data structure, so it doubles as a cache with infinite TTL as well. `MemoizeClientHandle` is publicly exported, and otherwise only used in tests. Deduplication and caching features should be added to `DnssecClient`, to bring it to parity with the recursor, and avoid wasted network traffic.

kerem added the

crate:client

feature:dnsssec

labels

2026-03-16 01:42:11 +03:00

kerem commented

2026-03-16 01:42:22 +03:00

Author

Owner

@djc commented on GitHub (Jul 14, 2025):

Deduplication and caching features should be added to DnssecClient, to bring it to parity with the recursor, and avoid wasted network traffic.

I don't think DnssecClient is a particularly important part of the stack right now? I'd hesitate to prioritize work on it unless that helps us modularize stuff in the resolver/recursor.

@djc commented on GitHub (Jul 14, 2025): > Deduplication and caching features should be added to `DnssecClient`, to bring it to parity with the recursor, and avoid wasted network traffic. I don't think `DnssecClient` is a particularly important part of the stack right now? I'd hesitate to prioritize work on it unless that helps us modularize stuff in the resolver/recursor.

kerem commented

2026-03-16 01:42:27 +03:00

Author

Owner

@divergentdave commented on GitHub (Jul 14, 2025):

Yeah, I had just noticed it while looking at integration tests and wanted to get it written down.

@divergentdave commented on GitHub (Jul 14, 2025): Yeah, I had just noticed it while looking at integration tests and wanted to get it written down.

kerem referenced this issue

2026-03-16 04:24:19 +03:00

[PR #1135] [CLOSED] Bump async-trait from 0.1.33 to 0.1.35 #2002