Can't resolve internal host name via IPv4 #1085
Comments
|
Can you share (feel free to remove the specific IP's and or names, but we need to understand the upstream resolver configuration, internal vs. external for example) of the I think what's possibly going on is that trust-dns is recognizing an upstream response from a public name service as being authoritative for I've been considering to loosen the current usage of this configuration option: https://docs.rs/trust-dns-resolver/0.19.4/trust_dns_resolver/config/struct.ResolverOpts.html#structfield.distrust_nx_responses, to include distrusting all NX and NoError responses as well. |
|
Alright I'll try to share as much as I can. So: My computer's network is managed by systemd-networkd and as the first resolver I use systemd-resolved. However, I also use dnsmasq after systemd-resolved to do some weirder stuff where I choose specific upstream DNS servers depending on the host. I'll illustrate this using actual config. 10.13.37.1 is my local network's router and my primary gateway. In this scenario, I'll try to reach So yes, the internal host I'm trying to reach does use an actual TLD just as you suspected. And yes, this kind of sucks on the enterprise's part. However, this is nothing I have control over and I'd like my Rust stuff to work even in this kind of situation. Obviously I can't expect any global authority to validate my internal host's validity but that's fine for my case. |
|
For reference, the only reserved DNS names are these: https://tools.ietf.org/html/rfc6761 See this thread for good understanding of why using non-reserved DNS names is dangerous: https://serverfault.com/questions/17255/top-level-domain-domain-suffix-for-private-network I'd highly recommend encouraging your enterprise to stop using a non-regerstered domain. This is a potential security vulnerability waiting to happen. As to fixing this, if you're interested in testing this, I think it could be done by expanding this to include NXDomain and NoError responses: https://github.com/bluejekyll/trust-dns/blob/76a3776d8840b4915390f241cda94d1f12b0df73/crates/resolver/src/name_server/name_server.rs#L141-L147 If that works, I was already considering expanding this for reasons like this. |
Yeah... I believe I'll need a few more years of convincing before making progress on that front. The implications are bad. :) I did some hacking but I don't really have any overview of this code base and barely have any idea what I'm doing. I did this: if self.options.distrust_nx_responses {
match response.response_code() {
ResponseCode::ServFail => {
let note = "Nameserver responded with SERVFAIL";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NXDomain => {
dbg!(&response.response_code());
let note = "Nameserver responded with NXDomain";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NoError => {
dbg!(&response.response_code());
let note = "Nameserver responded with NoError";
debug!("{}", note);
return Err(ProtoError::from(note));
}
_ => (),
}But I'm not sure I get the result of this: Probably not how you wanted me to hack this. :) |
|
That's the change I was expecting :) That's probably correct, as that it will now treat these as "failures" and not accurately as "NxDomain" which is technically a successful response. It will trigger the logic to continue trying to resolve the name. I see that you're still getting an error though, is it not finding the name you're looking for? |
|
Indeed, it still doesn't appear to resolve it. The code is the same as linked above: https://github.com/hatoo/oha-56 I put in drill is perfectly happy with my host: |
|
Oh, sorry, I've misled you I realize, I think I mislead you on the "NoError" state... That has to incorporate one more check, I bet if you run |
|
True, without your changes, a lot of tests are broken and they are happy if I add that condition. Sadly, it doesn't change anything in my particular case. Just to confirm, my code is now match response.response_code() {
ResponseCode::ServFail => {
let note = "Nameserver responded with SERVFAIL";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NXDomain => {
dbg!(&response.response_code());
let note = "Nameserver responded with NXDomain";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NoError if response.answers().is_empty() => {
dbg!(&response.response_code());
let note = "Nameserver responded with NoError";
debug!("{}", note);
return Err(ProtoError::from(note));
}
_ => (),
}and the output is the same as in #1085 (comment). Judging by the output, my case never hits that match arm anyway. |
|
Hm, that would imply we're never hitting your internal DNS server. Can you try configuring https://docs.rs/trust-dns-resolver/0.19.4/trust_dns_resolver/config/struct.ResolverOpts.html#structfield.num_concurrent_reqs to 1, I'm wondering if you're running into an existing other bug: #933 |
|
I now have #[tokio::main]
async fn main() -> anyhow::Result<()> {
let resolver = trust_dns_resolver::AsyncResolver::tokio(
Default::default(),
trust_dns_resolver::config::ResolverOpts {
ip_strategy: trust_dns_resolver::config::LookupIpStrategy::Ipv4Only, // oha --ipv4
num_concurrent_reqs: 1,
..Default::default()
},
)
.await?;
let addrs = resolver
.lookup_ip("enterprise.wtf") // put hostname here
.await?
.iter()
.collect::<Vec<_>>();
dbg!(addrs);
Ok(())
}and that didn't seem to change the behavior at all. |
|
We need to cleanup these APIs... ugg. So the issue with your new configuration, is that the Default ResolverConfig only uses the public Google DNS resolvers. You'll want to use this function to get your system's config: https://docs.rs/trust-dns-resolver/0.19.4/trust_dns_resolver/system_conf/fn.read_system_conf.html That should be easier to find. Then you can change any of the ResolverOpts as necessary, but it will start with the opts as read from the |
|
Oh gee, it turns out that we simply used that wrong then. Now when using However, I do run into #933 if I don't limit the concurrent requests to 1. |
|
All in all, I'm happy we quickly found the problem thanks to your help. It resulted in hatoo/oha#59 so at least we made the world a slightly better place. Keep rocking. |
|
That's great news. Is the concurrent lookup issue a bug with the code that you were experimenting with before? (the changes to error detection you made to |
|
I reverted my changes and then found out that I hit #933 and then I added the workaround and the spurious problems went away. Not sure what else I'm supposed to be checking. |
|
I was wondering if you could help debug #933, if you have time, I'm wondering if this: match response.response_code() {
ResponseCode::ServFail => {
let note = "Nameserver responded with SERVFAIL";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NXDomain => {
dbg!(&response.response_code());
let note = "Nameserver responded with NXDomain";
debug!("{}", note);
return Err(ProtoError::from(note));
}
ResponseCode::NoError if response.answers().is_empty() => {
dbg!(&response.response_code());
let note = "Nameserver responded with NoError";
debug!("{}", note);
return Err(ProtoError::from(note));
}
_ => (),
}Fixes that, if you have some time to check, it would help debug that other issue, with the concurrency set to something more than 1... |
Describe the bug
Carried over from hatoo/oha#56. Basically I got an internally resolvable host called
internal.host(IPv4-only) that I need to use an internal DNS server for.nslookupandhostwork just fine and can resolve the name.trust-dnscan't. I getTo Reproduce
https://github.com/hatoo/oha-56 was made by the author of oha to illustrate the problem.
Expected behavior
The host should resolve just fine like
nslookuporhost.System:
Version:
Crate: trust-dns-resolver
Version: 0.19.3
Additional context
See https://github.com/hatoo/oha-56 and hatoo/oha#56
The text was updated successfully, but these errors were encountered: