starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #470] QUERY_DEPTH attempt to add with overflow #199

New issue

Closed

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

kerem commented

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

Owner

Originally created by @DarrenTsung on GitHub (May 17, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/470

Hi, I'm trying to swap out the default DNS resolver in hyper with trust-dns and I'm seeing this panic when attempting to send out a lot of requests.

Full error:

thread 'Hyper-Client-Pool Executor' panicked at 'attempt to add with overflow', /Users/darrentsung/.cargo/registry/src/github.com-1ecc6299db9ec823/trust-dns-resolver-0.8.2/src/lookup_state.rs:64:30

The code in question:

...
    /// Perform a lookup against this caching client, looking first in the cache for a result
    pub fn lookup(&mut self, query: Query) -> Box<Future<Item = Lookup, Error = ResolveError>> {
        QUERY_DEPTH.with(|c| *c.borrow_mut() += 1);
...

This is reproducible by running the a_ton_of_notifications() test on my fork of hyper-client-pool which we're using to send notifications.

Fork: https://github.com/DarrenTsung/hyper-client-pool/tree/trust-dns.
I'm replacing the DNS resolver with this repo: https://github.com/DarrenTsung/hyper-http-connector/tree/trust-dns-cache-resolver.

Does anyone have any ideas why this might be happening? It might be related to how I implemented trust-dns resolver?

I have a c-ares implementation that works, but it would be great to use trust-dns for this as we use it elsewhere in our notification pipeline!

Originally created by @DarrenTsung on GitHub (May 17, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/470 Hi, I'm trying to swap out the default DNS resolver in `hyper` with `trust-dns` and I'm seeing this panic when attempting to send out a lot of requests. Full error: ``` thread 'Hyper-Client-Pool Executor' panicked at 'attempt to add with overflow', /Users/darrentsung/.cargo/registry/src/github.com-1ecc6299db9ec823/trust-dns-resolver-0.8.2/src/lookup_state.rs:64:30 ``` The code in question: ``` ... /// Perform a lookup against this caching client, looking first in the cache for a result pub fn lookup(&mut self, query: Query) -> Box<Future<Item = Lookup, Error = ResolveError>> { QUERY_DEPTH.with(|c| *c.borrow_mut() += 1); ... ``` This is reproducible by running the `a_ton_of_notifications()` test on my fork of `hyper-client-pool` which we're using to send notifications. Fork: https://github.com/DarrenTsung/hyper-client-pool/tree/trust-dns. I'm replacing the DNS resolver with this repo: https://github.com/DarrenTsung/hyper-http-connector/tree/trust-dns-cache-resolver. Does anyone have any ideas why this might be happening? It might be related to how I implemented trust-dns resolver? I have a c-ares implementation that works, but it would be great to use trust-dns for this as we use it elsewhere in our notification pipeline!

kerem

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

closed this issue
added the
duplicate

crate:resolver
labels

kerem commented

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

Author

Owner

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

Which version of TRust-DNS Resolver are you using? I just patched a similar issue recently: #469

Also, I just published new versions of the libraries on crates.io, I'm in the middle of writing up the announcement.

@bluejekyll commented on GitHub (May 18, 2018): Which version of TRust-DNS Resolver are you using? I just patched a similar issue recently: #469 Also, I just published new versions of the libraries on crates.io, I'm in the middle of writing up the announcement.

kerem commented

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

Author

Owner

@DarrenTsung commented on GitHub (May 18, 2018):

Using 0.8, I see you pushed up 0.9 to crates.io. I can update the branch and see if it still happens!

@DarrenTsung commented on GitHub (May 18, 2018): Using 0.8, I see you pushed up 0.9 to crates.io. I can update the branch and see if it still happens!

kerem commented

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

Author

Owner

@DarrenTsung commented on GitHub (May 18, 2018):

Did an update to 0.9, the panic no longer occurs but I'm seeing a lot of errors and no requests going through:


running 1 test
ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified
ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified
ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified
ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified
ERROR 2018-05-18T00:24:02Z: trust_dns_proto::xfer::dns_future: error in Proto: io error
ERROR 2018-05-18T00:24:02Z: trust_dns_proto::xfer::dns_future: error in Proto: io error
test a_ton_of_notifications ... FAILED

The error messages aren't really saying too much on what's happening.

@DarrenTsung commented on GitHub (May 18, 2018): Did an update to 0.9, the panic no longer occurs but I'm seeing a lot of errors and no requests going through: ``` running 1 test ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified ERROR 2018-05-18T00:23:16Z: trust_dns_proto::xfer::dns_future: error in Proto: no error specified ERROR 2018-05-18T00:24:02Z: trust_dns_proto::xfer::dns_future: error in Proto: io error ERROR 2018-05-18T00:24:02Z: trust_dns_proto::xfer::dns_future: error in Proto: io error test a_ton_of_notifications ... FAILED ``` The error messages aren't really saying too much on what's happening.

kerem commented

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

Author

Owner

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

I'm sorry, I don't have time right now to dig into your issue. But I recently put together an example that might help you: https://github.com/bluejekyll/trust-dns/blob/master/resolver/examples/global_resolver.rs

@bluejekyll commented on GitHub (May 18, 2018): I'm sorry, I don't have time right now to dig into your issue. But I recently put together an example that might help you: https://github.com/bluejekyll/trust-dns/blob/master/resolver/examples/global_resolver.rs

kerem commented

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

Author

Owner

@DarrenTsung commented on GitHub (May 18, 2018):

👍 Thanks for the example, no worries, I appreciate all the help!

@DarrenTsung commented on GitHub (May 18, 2018): 👍 Thanks for the example, no worries, I appreciate all the help!

kerem commented

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

Author

Owner

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

Is this issue resolved?

@bluejekyll commented on GitHub (May 18, 2018): Is this issue resolved?

kerem commented

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

Author

Owner

@DarrenTsung commented on GitHub (May 18, 2018):

No, I haven't taken a look at fixing this as c-ares is working for us right now. The issue can still be reproduced on the trust-dns branch of our repo:

https://github.com/DarrenTsung/hyper-client-pool/tree/trust-dns

@DarrenTsung commented on GitHub (May 18, 2018): No, I haven't taken a look at fixing this as c-ares is working for us right now. The issue can still be reproduced on the `trust-dns` branch of our repo: https://github.com/DarrenTsung/hyper-client-pool/tree/trust-dns

kerem commented

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

Author

Owner

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

It looks like tokio-core is being used there. Not sure if that’s an issue.

@bluejekyll commented on GitHub (May 18, 2018): It looks like tokio-core is being used there. Not sure if that’s an issue.

kerem commented

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

Author

Owner

@DarrenTsung commented on GitHub (May 24, 2018):

Replacing the tokio-core implementation with the global resolver fixed the issue, thanks for the suggestion!

@DarrenTsung commented on GitHub (May 24, 2018): Replacing the tokio-core implementation with the global resolver fixed the issue, thanks for the suggestion!

kerem commented

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

Author

Owner

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

Awesome!

@bluejekyll commented on GitHub (May 24, 2018): Awesome!

kerem referenced this issue

2026-03-15 22:13:24 +03:00

[GH-ISSUE #180] When *ring* feature is enabled, use it for RSA and other supported DNSSec proofs #384

kerem referenced this issue

2026-03-16 01:58:53 +03:00