[PR #1923] [CLOSED] Add AsyncResolverBuilder and option to overide a pre-created cache #2699

New issue

Closed

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

kerem commented

2026-03-16 11:03:18 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/1923
Author: @hottea773
Created: 4/28/2023
Status: ❌ Closed

Base: main ← Head: main

📝 Commits (2)

67a98f9 Add AsyncResolverBuilder to allow sharing a cache
d9612eb Make AsyncResolverBuilder fully-featured

📊 Changes

3 files changed (+205 additions, -52 deletions)

View changed files

📝 Cargo.lock (+37 -0)
📝 crates/resolver/src/async_resolver.rs (+166 -50)
📝 crates/resolver/src/lib.rs (+2 -2)

📄 Description

This PR adds the ability to share a DNS Cache between different AsyncResolvers. It also add an AsyncResolverBuilder to avoid adding yet more new_with_... methods to the AsyncResolver.

The rough reasoning behind it was that we've got a few different threads running all of which need to make DNS requests, but we didn't want to be making unnecessary requests if we've already done a previous lookup; hence a desire for multiple AsyncResolvers to shared their cache.

Since we did this work initially, I've thought that perhaps we could just have each thread use a clone of an initial AsyncResolver, which would mean that they shared the cache, since it's an Arc, so perhaps this change is unnecessary?

So I guess I have a question for reviewers:

Would there be any performance (or other) impact to using cloned AsyncResolver across multiple threads at the same time. Looking through the struct, I see that there are a few other items behind Arcs, such as https://github.com/bluejekyll/trust-dns/blob/main/crates/resolver/src/name_server/name_server_pool.rs#L39-L40 which I fear might cause some kind of issues, but don't really feel like I know enough to know.

If you don't think there would be any impact from that, then this PR is probably unnecessary (unless you disagree).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/1923 **Author:** [@hottea773](https://github.com/hottea773) **Created:** 4/28/2023 **Status:** ❌ Closed **Base:** `main` ← **Head:** `main` --- ### 📝 Commits (2) - [`67a98f9`](https://github.com/hickory-dns/hickory-dns/commit/67a98f9665b46f2f21f50d451e8f0830191ce726) Add AsyncResolverBuilder to allow sharing a cache - [`d9612eb`](https://github.com/hickory-dns/hickory-dns/commit/d9612ebf87ee697140a4967a371813c24f0f6fc2) Make AsyncResolverBuilder fully-featured ### 📊 Changes **3 files changed** (+205 additions, -52 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+37 -0) 📝 `crates/resolver/src/async_resolver.rs` (+166 -50) 📝 `crates/resolver/src/lib.rs` (+2 -2) </details> ### 📄 Description This PR adds the ability to share a DNS Cache between different `AsyncResolver`s. It also add an `AsyncResolverBuilder` to avoid adding yet more `new_with_...` methods to the `AsyncResolver`. The rough reasoning behind it was that we've got a few different threads running all of which need to make DNS requests, but we didn't want to be making unnecessary requests if we've already done a previous lookup; hence a desire for multiple `AsyncResolver`s to shared their cache. Since we did this work initially, I've thought that perhaps we could just have each thread use a `clone` of an initial `AsyncResolver`, which would mean that they shared the cache, since it's an `Arc`, so perhaps this change is unnecessary? So I guess I have a question for reviewers: Would there be any performance (or other) impact to using cloned `AsyncResolver` across multiple threads at the same time. Looking through the struct, I see that there are a few other items behind `Arc`s, such as https://github.com/bluejekyll/trust-dns/blob/main/crates/resolver/src/name_server/name_server_pool.rs#L39-L40 which I fear might cause some kind of issues, but don't really feel like I know enough to know. If you don't think there would be any impact from that, then this PR is probably unnecessary (unless you disagree). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>