[GH-ISSUE #431] Names like "1.2.3.4" are wrongly assumed to be IP addresses #485

New issue

Closed

opened 2026-03-15 22:45:17 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 22:45:17 +03:00

Owner

Originally created by @briansmith on GitHub (Apr 26, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/431

ResolverFuture::lookup_ip() contains this:

        // if host is a ip address, return directly.
        if let Some(addr) = parse_literal_ip(host) {
            return InnerLookupIpFuture::ok(
                self.client_cache.clone(),
                Lookup::new(Arc::new(vec![addr])),
            );
        }

This is not correct. Consider a /etc/resolv.conf like this:

nameserver 10.96.0.10
search x.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

I should be able to do a DNS lookup on "1.2.3.4" and Trust-DNS should search "1.2.3.4.x.svc.cluster.local" then "1.2.3.4.svc.cluster.local" then "1.2.3.4.cluster.local". Try dig +showsearch 1.2.3.4 for example.

Thus, all "try parsing it as an IP address first" like the one given above should be removed.

Originally created by @briansmith on GitHub (Apr 26, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/431 `ResolverFuture::lookup_ip()` contains this: ```rust // if host is a ip address, return directly. if let Some(addr) = parse_literal_ip(host) { return InnerLookupIpFuture::ok( self.client_cache.clone(), Lookup::new(Arc::new(vec![addr])), ); } ``` This is not correct. Consider a /etc/resolv.conf like this: ``` nameserver 10.96.0.10 search x.svc.cluster.local svc.cluster.local cluster.local options ndots:5 ``` I should be able to do a DNS lookup on "1.2.3.4" and Trust-DNS should search "1.2.3.4.x.svc.cluster.local" then "1.2.3.4.svc.cluster.local" then "1.2.3.4.cluster.local". Try `dig +showsearch 1.2.3.4` for example. Thus, all "try parsing it as an IP address first" like the one given above should be removed.

kerem

2026-03-15 22:45:17 +03:00

closed this issue
added the
bug

crate:resolver
labels

kerem commented

2026-03-15 22:45:34 +03:00

Author

Owner

@briansmith commented on GitHub (Apr 26, 2018):

Note: I gave an example using a Kubernetes configuration, but this isn't really impacting any Kubernetes applications because "1.2.3.4" isn't a valid service name and "4" isn't a valid namespace name.

@briansmith commented on GitHub (Apr 26, 2018): Note: I gave an example using a Kubernetes configuration, but this isn't really impacting any Kubernetes applications because "1.2.3.4" isn't a valid service name and "4" isn't a valid namespace name.

kerem commented

2026-03-15 22:45:39 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 26, 2018):

I just reviewed https://tools.ietf.org/html/rfc1123 and you are correct. So annoying that DNS and IP use the same delimeters.

I’ll double check, but the easy fix will be to move this into the FQDN lookup, and evaluate there. We need to double check how things like glibc deal with this.

@bluejekyll commented on GitHub (Apr 26, 2018): I just reviewed https://tools.ietf.org/html/rfc1123 and you are correct. So annoying that DNS and IP use the same delimeters. I’ll double check, but the easy fix will be to move this into the FQDN lookup, and evaluate there. We need to double check how things like glibc deal with this.

kerem referenced this issue

2026-03-16 02:08:23 +03:00

[PR #485] [MERGED] resolver: Propagate TTLs for NXDOMAIN responses #1471