"proto error" was returned from lookup_ip #905
Comments
|
Do you have the code for how tokio itself is being instantiated? |
|
In some of the async/await changes, I think some lazy's were removed, this could be an issue in some cases. Possibly cause the issue your seeing, though I don't see that in any of the tests, which is why I'm wondering how Tokio is being instantiated in your examples. |
|
I am using #[tokio::main]
async fn main() {
// ...
} |
|
This is how I instantiated tokio: https://github.com/shadowsocks/shadowsocks-rust/blob/feature-migrate-async-await/src/bin/server.rs#L25 . In
|
|
Ok, using this comparison: 4858edd...master My guess is that some of the lazy's that were removed in that patch are causing issues. update: I looked through both the changes to resolver code and proto code to see if there was a lazy removed that would cause issues, and I don't see it. So I'm not sure that lazy is the issue here. |
|
@zonyitoo if you have time, do you think you could throw together a test case that we can reproduce this problem with and we could use that as the basis for finding this issue and making sure it doesn’t happen again? |
|
Minimun test case: use trust_dns_resolver::AsyncResolver;
use trust_dns_resolver::system_conf::read_system_conf;
use tokio;
#[tokio::main]
async fn main() {
let (config, opts) = read_system_conf().expect("Failed to read global dns sysconf");
let (resolver, bg) = AsyncResolver::new(config, opts);
tokio::spawn(bg);
let resolved = resolver.lookup_ip("www.example.com").await.unwrap();
println!("{:?}", resolved);
}
[dependencies]
trust-dns-resolver = { git = "https://github.com/bluejekyll/trust-dns", features = ["dns-over-rustls", "dns-over-https-rustls"] }
tokio = { git = "https://github.com/tokio-rs/tokio" }Rust version Build and run with result (with all deps versions): I can reproduce it everytime on my macbook. |
|
Ok, thanks. I'll pull this into the repo and use as a new test case to make sure we're compatible with the usage of I might have time to look at this tonight, but can't guarantee it. |
|
I don't think use trust_dns_resolver::AsyncResolver;
use trust_dns_resolver::system_conf::read_system_conf;
use tokio;
use tokio::runtime::Runtime;
fn main() {
let runtime = Runtime::new().unwrap();
let resolved = runtime.block_on(async {
let (config, opts) = read_system_conf().expect("Failed to read global dns sysconf");
let (resolver, bg) = AsyncResolver::new(config, opts);
tokio::spawn(bg);
resolver.lookup_ip("www.example.com").await
}).unwrap();
println!("{:?}", resolved);
}I can get exactly the same result: |
|
This is exactly the test in async_resolver/mod.rs. use trust_dns_resolver::config::{ResolverConfig, ResolverOpts};
use trust_dns_resolver::AsyncResolver;
use tokio::runtime::Runtime;
fn main() {
let runtime = Runtime::new().unwrap();
let (resolver, bg) = AsyncResolver::new(ResolverConfig::default(), ResolverOpts::default());
runtime.spawn(bg);
let resolved = runtime.block_on(resolver.lookup_ip("www.example.com")).unwrap();
println!("{:?}", resolved);
}Not surprised ... |
I wasn't implying it's at fault, just that it's exposing an issue in the library that wasn't there before. What's confusing here is that this test passes in CI without issue, and on mac (also locally for me as well): https://travis-ci.org/bluejekyll/trust-dns/jobs/604008906#L827 (edit: had link to wrong line before) I wonder if we're masking some other error? |
|
Ok, here's why the tests are passing, change your dependency on tokio to So something about tokio master is different enough to break trust-dns. |
|
Ok, see feedback on linked issue. After looking at the cargo tree output, I think it's clear that there are multiple dependency versions being used at once from tokio. Please use |
|
Well, it works after changing deps of |
|
Closing now. |
|
If you want to use master, you’ll need do something to tell all the trust-dns libraries to also use master, it is possible: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies |
|
That's very helpful!! Thanks! |
|
But it seems that trust-dns cannot build with tokio's master |
|
These two errors could be fixed by replacing |
|
We don’t want to directly depend on Tokio, as that pulls in too many dependencies for the proto library. Did you override the version dependency for all of the Tokio child libraries? |
|
I don't think that will work. Some of the child libraries have been merged completely into |
|
sub crate tokio-net was removed in tokio trunk: |
|
Thanks for this note. I’m going to ping the Tokio dev channel to get some guidance. |
|
Remind: tokio v0.2.0 is released. |
|
I think I ran into the same issue after upgrading from osx 10.12 to 10.13. I'm on trust-dns 0.17.0 and trust-dns-proto 0.8.0. Removing the fe80::/10 address from /etc/resolv.conf fixed this. I assume this error might be related to ipv6. |
|
Any chance you can upgrade to 0.19? |
|
Already upgraded. But found another warnings: But errors in this issue is not showing again. |
- temporary bypassed hickory-dns/hickory-dns#905
- temporary bypassed hickory-dns/hickory-dns#905
- temporary bypassed hickory-dns/hickory-dns#905
Describe the bug
I was using
AsyncResolverwithread_system_conf(). I have got "proto error" when resolving any addresses. Some useful logs are here:To Reproduce
Steps to reproduce the behavior:
Create a
AsyncResolverwithread_system_confCall
lookup_ipwith any addressesExpected behavior
lookup_ipshould return valid IPs instead of errors.System:
Version:
Crate: resolver
Version: master on github
The text was updated successfully, but these errors were encountered: