starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

resolv.conf #716

New issue

Closed

opened 2026-03-15 23:57:24 +03:00 by kerem · 8 comments

kerem commented

2026-03-15 23:57:24 +03:00

Owner

Originally created by @jofas on GitHub (Feb 16, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1637

Hi,

I have a VPN connection to my kubernetes cluster and rely on providing the nameserver of that cluster statically via the /etc/resolv.conf file. That allows me to connect my local machine to the cluster and I can run my test suite locally, but within the environment my program will later run in.

My /etc/resolv.conf looks like this:

search fritz.box
# the kubernetes dns
nameserver 10.1.1.1
# my local dns that handles resolving when I'm not connected via VPN
nameserver 192.168.1.1

I've run the following program, with trust-dns-resolver v0.19.7, v0.20.4 and v0.21.0-alpha.5, trying to get the ip address of a service running in my cluster:

use trust_dns_resolver::Resolver;

fn main() {
  let resolver = Resolver::from_system_conf().unwrap();

  let response = resolver.lookup_ip("some-service.default.svc.cluster.local").unwrap();

  println!("{:?}", response);
}

Works as expected with v0.21.0-alpha.5, returning the ip address of that service. Both v0.19.7 (I use actix which relies on that version) and v0.20.4 throw an error that they are unable to resolve that name. To me it seems to be an issue that two nameserver are provided, when I delete my local dns server, they are able to resolve the service name.

What has changed in v0.21.0-alpha.5 compared to the older versions? And would it be possible to implement a hotfix for v0.19 (and v0.20)

Kind regards,

System:

OS: linux
Architecture: x86_64
rustc version: 1.58.1

Originally created by @jofas on GitHub (Feb 16, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1637 Hi, I have a VPN connection to my kubernetes cluster and rely on providing the nameserver of that cluster statically via the `/etc/resolv.conf` file. That allows me to connect my local machine to the cluster and I can run my test suite locally, but within the environment my program will later run in. My `/etc/resolv.conf` looks like this: ``` search fritz.box # the kubernetes dns nameserver 10.1.1.1 # my local dns that handles resolving when I'm not connected via VPN nameserver 192.168.1.1 ``` I've run the following program, with `trust-dns-resolver` `v0.19.7`, `v0.20.4` and `v0.21.0-alpha.5`, trying to get the ip address of a service running in my cluster: ```rust use trust_dns_resolver::Resolver; fn main() { let resolver = Resolver::from_system_conf().unwrap(); let response = resolver.lookup_ip("some-service.default.svc.cluster.local").unwrap(); println!("{:?}", response); } ``` Works as expected with `v0.21.0-alpha.5`, returning the ip address of that service. Both `v0.19.7` (I use `actix` which relies on that version) and `v0.20.4` throw an error that they are unable to resolve that name. To me it seems to be an issue that two `nameserver` are provided, when I delete my local dns server, they are able to resolve the service name. What has changed in `v0.21.0-alpha.5` compared to the older versions? And would it be possible to implement a hotfix for `v0.19` (and `v0.20`) Kind regards, **System:** - OS: `linux` - Architecture: `x86_64` - rustc version: `1.58.1`

kerem closed this issue

2026-03-15 23:57:30 +03:00

kerem commented

2026-03-15 23:57:36 +03:00

Author

Owner

@djc commented on GitHub (Feb 16, 2022):

Since you have a reproducible test case already, maybe you can just use git bisect to find the offending commit?

@djc commented on GitHub (Feb 16, 2022): Since you have a reproducible test case already, maybe you can just use git bisect to find the offending commit?

kerem commented

2026-03-15 23:57:41 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 17, 2022):

~~I think this has to do with the trust_nx patches that went in possibly fixing this. Can you check if 0.21.0.alpha.5 is better?~~

Sorry, just reread your post, I see that you did try this.

What has changed in v0.21.0-alpha.5 compared to the older versions?

Quite a bit. We plan to release 0.21 soonish, can you use the alpha as is for now?

@bluejekyll commented on GitHub (Feb 17, 2022): ~~I think this has to do with the trust_nx patches that went in possibly fixing this. Can you check if `0.21.0.alpha.5` is better?~~ Sorry, just reread your post, I see that you did try this. > What has changed in v0.21.0-alpha.5 compared to the older versions? Quite a bit. We plan to release 0.21 soonish, can you use the alpha as is for now?

kerem commented

2026-03-15 23:57:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 17, 2022):

also, btw, for future reference, you can use the resolve command out of the trust-dns-util crate for testing the resolver and it's various configs.

@bluejekyll commented on GitHub (Feb 17, 2022): also, btw, for future reference, you can use the `resolve` command out of the `trust-dns-util` crate for testing the resolver and it's various configs.

kerem commented

2026-03-15 23:57:51 +03:00

Author

Owner

@jofas commented on GitHub (Feb 17, 2022):

I did as @djc suggested and bisected till I found the fixing commit. Turns out 227105a (in the v0.21.0-alpha.3 release) fixes my issue.

Correct me if I'm wrong, but to me it seems the commit has fixed an issue where lacking records were not treated as errors, causing the resolver not to retry (in my case causing the resolver to query a different nameserver that has the record present).

Unfortunately, I don't think that just upgrading my dependency is a viable option, because the resolver is deeply buried within the actix framework and I don't think the actix maintainers are very interested in updating the version of the resolver.

Could I try an see if I'm able to apply the fix from 227105a to the v0.19 and v0.20 versions? Would you consider releasing the fix as v0.19.8/v0.20.5?

@jofas commented on GitHub (Feb 17, 2022): I did as @djc suggested and bisected till I found the fixing commit. Turns out `227105a` (in the `v0.21.0-alpha.3` release) fixes my issue. Correct me if I'm wrong, but to me it seems the commit has fixed an issue where lacking records were not treated as errors, causing the resolver not to retry (in my case causing the resolver to query a different nameserver that has the record present). Unfortunately, I don't think that just upgrading my dependency is a viable option, because the resolver is deeply buried within the `actix` framework and I don't think the `actix` maintainers are very interested in updating the version of the resolver. Could I try an see if I'm able to apply the fix from `227105a` to the `v0.19` and `v0.20` versions? Would you consider releasing the fix as `v0.19.8/v0.20.5`?

kerem commented

2026-03-15 23:57:56 +03:00

Author

Owner

@djc commented on GitHub (Feb 17, 2022):

You might be able to patch the dependency using a patch section in the Cargo manifest. (Depends if the actix code depends on APIs that changed.)

I do think it could make sense to backport that particular change, since it fixes a regression. Up to @bluejekyll if he's up for publishing updates to crates.io though.

@djc commented on GitHub (Feb 17, 2022): You might be able to patch the dependency using [a patch section](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section) in the Cargo manifest. (Depends if the actix code depends on APIs that changed.) I do think it could make sense to backport that particular change, since it fixes a regression. Up to @bluejekyll if he's up for publishing updates to crates.io though.

kerem commented

2026-03-15 23:58:01 +03:00

Author

Owner

@jofas commented on GitHub (Feb 17, 2022):

Thanks for the tip. I tried to patch it but there's a version conflict for tokio. actix-web v3 still relies on the tokio v0.2 runtime and does not yet support v1, unfortunately.

@jofas commented on GitHub (Feb 17, 2022): Thanks for the tip. I tried to patch it but there's a version conflict for tokio. `actix-web v3` still relies on the `tokio v0.2` runtime and does not yet support `v1`, unfortunately.

kerem commented

2026-03-15 23:58:06 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 17, 2022):

Yes, we can backport if the change isn’t significant. 0.20 seems reasonable. 0.19 tests are almost guaranteed to fail because that branch is pretty outdated. I’d be uncomfortable publishing a new patch on 0.19 at this point. It probably has audit failures as well.

@bluejekyll commented on GitHub (Feb 17, 2022): Yes, we can backport if the change isn’t significant. 0.20 seems reasonable. 0.19 tests are almost guaranteed to fail because that branch is pretty outdated. I’d be uncomfortable publishing a new patch on 0.19 at this point. It probably has audit failures as well.

kerem commented

2026-03-15 23:58:12 +03:00

Author

Owner

@jofas commented on GitHub (Feb 17, 2022):

Yes, I thought this might be. Applying the changes from 227105a to v0.20.4 is relatively straight-forward (though I'm unable to get the test_distrust_nx_responses integration test running). v0.19.7 looks a lot different (e.g. NameServer.inner_send returns ProtoError instead of ResolveError and ResolveError::from_response isn't part of the release).

I think I'll just write a script that removes my local dns when I establish the VPN. Thanks for the support.

@jofas commented on GitHub (Feb 17, 2022): Yes, I thought this might be. Applying the changes from `227105a` to `v0.20.4` is relatively straight-forward (though I'm unable to get the `test_distrust_nx_responses` integration test running). `v0.19.7` looks a lot different (e.g. `NameServer.inner_send` returns `ProtoError` instead of `ResolveError` and `ResolveError::from_response` isn't part of the release). I think I'll just write a script that removes my local dns when I establish the VPN. Thanks for the support.

kerem referenced this issue

2026-03-16 02:16:47 +03:00

[PR #716] [MERGED] Bump lru-cache from 0.1.1 to 0.1.2 #1626