[GH-ISSUE #423] It should be possible to use a single DNS configuration/options object for multiple lookups #483

New issue

Closed

opened 2026-03-15 22:44:51 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 22:44:51 +03:00

Owner

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

My application reads the configuration files (/etc/resolv.conf, /etc/hosts, etc.) using trust_dns_resolver::system_conf::read_system_conf() once at startup. I'd like to reuse the config/opts objects it returns for multiple asynchronous lookups. However, ResolverFuture::new() uses move semantics for its config and options arguments. I think it would be better to have ResolverFuture::new() take Rc<>s instead.

Originally created by @briansmith on GitHub (Apr 24, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/423 My application reads the configuration files (/etc/resolv.conf, /etc/hosts, etc.) using `trust_dns_resolver::system_conf::read_system_conf()` once at startup. I'd like to reuse the config/opts objects it returns for multiple asynchronous lookups. However, `ResolverFuture::new()` uses move semantics for its `config` and `options` arguments. I think it would be better to have `ResolverFuture::new()` take `Rc<>s` instead.

kerem closed this issue

2026-03-15 22:44:56 +03:00

kerem commented

2026-03-15 22:45:02 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 24, 2018):

I'm guessing this means that in your use case the resolver is not long lived. I think this is fine. Right now ResolverOpts is fairly cheap, so that's copy. Right now, there are some restrictions on ResolverFuture, which I think will require Arc. Any issue with that?

@bluejekyll commented on GitHub (Apr 24, 2018): I'm guessing this means that in your use case the resolver is not long lived. I think this is fine. Right now ResolverOpts is fairly cheap, so that's copy. Right now, there are some restrictions on ResolverFuture, which I think will require `Arc`. Any issue with that?

kerem commented

2026-03-15 22:45:07 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 25, 2018):

Out of curiosity, why not keep the ResolverFuture itself around instead just the Config? Is there a concern with that?

@bluejekyll commented on GitHub (Apr 25, 2018): Out of curiosity, why not keep the ResolverFuture itself around instead just the Config? Is there a concern with that?

kerem commented

2026-03-15 22:45:12 +03:00

Author

Owner

@briansmith commented on GitHub (Apr 26, 2018):

I agree that I should just reuse the ResolverFuture, but it is unclear if I can correctly do so in my project until #430 is resolved. I'm going to close this and I think PR #424 should be closed too,

@briansmith commented on GitHub (Apr 26, 2018): I agree that I should just reuse the `ResolverFuture`, but it is unclear if I can correctly do so in my project until #430 is resolved. I'm going to close this and I think PR #424 should be closed too,

kerem referenced this issue

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

[GH-ISSUE #483] Resolver binary #501

kerem referenced this issue

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

[GH-ISSUE #490] Add (optional) serde support for types in trust_dns_resolver::config #502

kerem referenced this issue

2026-03-15 22:56:02 +03:00

[GH-ISSUE #531] Building a recursor with trust-dns-server #521

kerem referenced this issue

2026-03-15 22:56:07 +03:00

[GH-ISSUE #531] Building a recursor with trust-dns-server #521