[GH-ISSUE #464] Split ResolverFuture::new() into two returns (ResolverHandle, ResolverRuntime) #200

New issue

Closed

opened 2026-03-07 22:45:32 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @bluejekyll on GitHub (May 14, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/464

Names TBD.

At the moment, ResolverFuture returns a lazily evaluated future of Self. This makes it complicated to use in multithreaded situations. The reason for this is that there are really two separate parts to the resolver, but one is hidden at the moment. The hidden part is the registration of the network connections, etc, in the NameServerPool and it's associated NameServers.

The proposed ResolverHandle (name TBD) would have an API identical to ResolverFuture today. It's responsibility would be identical to that of the ResolverFuture today, which is to use the handles to the NameServers to make requests.

The ResolverRuntime needs to be run in the background. This can be on the same thread as the ResolverHandle requests or on a separate thread. It should be spawned, and shut itself down when there are no more ResolverHandle's outstanding to it. To refactor the library to return this future, rather than spawning implicitly will take a bit of work, potentially all the way down into the proto library.

This should improve the experience of constructing and then using the Resolver...

Originally created by @bluejekyll on GitHub (May 14, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/464 Names TBD. At the moment, `ResolverFuture` returns a lazily evaluated future of `Self`. This makes it complicated to use in multithreaded situations. The reason for this is that there are really two separate parts to the resolver, but one is hidden at the moment. The hidden part is the registration of the network connections, etc, in the `NameServerPool` and it's associated `NameServer`s. The proposed `ResolverHandle` (name TBD) would have an API identical to `ResolverFuture` today. It's responsibility would be identical to that of the `ResolverFuture` today, which is to use the handles to the `NameServers` to make requests. The `ResolverRuntime` needs to be run in the background. This can be on the same thread as the `ResolverHandle` requests or on a separate thread. It should be spawned, and shut itself down when there are no more `ResolverHandle's` outstanding to it. To refactor the library to return this future, rather than spawning implicitly will take a bit of work, potentially all the way down into the proto library. This should improve the experience of constructing and then using the Resolver...

kerem

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

closed this issue
added the
cleanup

crate:resolver
labels

kerem commented

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

Author

Owner

@hawkw commented on GitHub (May 23, 2018):

I have some thoughts on how to do this. I'd be happy to start a branch.

@hawkw commented on GitHub (May 23, 2018): I have some thoughts on how to do this. I'd be happy to start a branch.

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (May 23, 2018):

I’m open to other proposals as well... this was just my first take on what might be needed.

@bluejekyll commented on GitHub (May 23, 2018): I’m open to other proposals as well... this was just my first take on what might be needed.

kerem commented

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

Author

Owner

@hawkw commented on GitHub (May 23, 2018):

Well, I'm not going to make any promises until it's done, but I think I've worked out a way of making this change without touching anything outside of the resolver crate.

@hawkw commented on GitHub (May 23, 2018): Well, I'm not going to make any promises until it's done, but I _think_ I've worked out a way of making this change without touching anything outside of the resolver crate.

kerem commented

2026-03-07 22:46:03 +03:00

Author

Owner

@hawkw commented on GitHub (May 23, 2018):

Okay, I have a working first pass on this in this branch.

In particular, you may want to check out this test I added, demonstrating that we can run the background task in a separate runtime on its' own thread from the futures returned by the ResolverHandle.

This branch probably still needs a little more polish before its' ready for prime-time. I think some of the code can be cleaned up, and it probably needs more documentation updates.

@hawkw commented on GitHub (May 23, 2018): Okay, I have a working first pass on this in [this branch](https://github.com/bluejekyll/trust-dns/compare/master...hawkw:eliza/split-resolver-future?expand=1). In particular, you may want to check out [this test I added](https://github.com/hawkw/trust-dns/blob/5ad62f466e037245da35c8ed6c25c2c76704e83e/resolver/src/resolver_future.rs#L605-L639), demonstrating that we can run the background task in a separate runtime on its' own thread from the futures returned by the `ResolverHandle`. This branch probably still needs a little more polish before its' ready for prime-time. I think some of the code can be cleaned up, and it probably needs more documentation updates.

kerem referenced this issue

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

[GH-ISSUE #200] DNSSEC Signature verification doesn't verify actual bytes received on the wire #390

kerem referenced this issue

2026-03-15 22:16:08 +03:00

[GH-ISSUE #205] Create Proto crate: better SoC for Signer/Verifier, KeyPair/PublicKey, etc. #389