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 #197] resolver should return directly, when use a `ip address` as a argument? #388

New issue

Closed

opened 2026-03-15 22:15:27 +03:00 by kerem · 11 comments

kerem commented

2026-03-15 22:15:27 +03:00

Owner

Originally created by @cssivision on GitHub (Sep 22, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/197

i do not see similar logic in the code, this can avoid useless dns query.

Originally created by @cssivision on GitHub (Sep 22, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/197 i do not see similar logic in the code, this can avoid useless dns query.

kerem

2026-03-15 22:15:27 +03:00

closed this issue
added the
enhance

crate:resolver
labels

kerem commented

2026-03-15 22:15:43 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 22, 2017):

I’m not sure if that is best practice or not. I understand the desire. Do you know how other resolvers deal with that case?

@bluejekyll commented on GitHub (Sep 22, 2017): I’m not sure if that is best practice or not. I understand the desire. Do you know how other resolvers deal with that case?

kerem commented

2026-03-15 22:15:48 +03:00

Author

Owner

@cssivision commented on GitHub (Sep 23, 2017):

extreme pursuit for performance...

@cssivision commented on GitHub (Sep 23, 2017): extreme pursuit for performance...

kerem commented

2026-03-15 22:15:53 +03:00

Author

Owner

@cssivision commented on GitHub (Sep 23, 2017):

if we decide to do this, i can fire a pr.

@cssivision commented on GitHub (Sep 23, 2017): if we decide to do this, i can fire a pr.

kerem commented

2026-03-15 22:15:58 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 23, 2017):

So the reason I'm concerned about this is that it's not clear to me that it's the responsibility of the resolver. i.e. I feel like, if you ask for name resolution, you expect it to be resolved :)

One option is that we could restrict the interface to TryInto<Name>, which I've been thinking of doing. That might make this more clear? For example, reverse Ip lookups are restricted to IpAddr.

I'm open to it, I just want to know what other resolvers out there do in this case...

@bluejekyll commented on GitHub (Sep 23, 2017): So the reason I'm concerned about this is that it's not clear to me that it's the responsibility of the resolver. i.e. I feel like, if you ask for name resolution, you expect it to be resolved :) One option is that we could restrict the interface to `TryInto<Name>`, which I've been thinking of doing. That might make this more clear? For example, reverse Ip lookups are restricted to `IpAddr`. I'm open to it, I just want to know what other resolvers out there do in this case...

kerem commented

2026-03-15 22:16:03 +03:00

Author

Owner

@cssivision commented on GitHub (Sep 23, 2017):

Now, if i use ip addr as input will get None as a return value.

i investigate the golang std lib method net.LookupIP i found it actually not implement the query, it just return the ip directly.

@cssivision commented on GitHub (Sep 23, 2017): Now, if i use `ip addr` as input will get `None` as a return value. i investigate the golang std lib method `net.LookupIP` i found it actually not implement the query, it just return the `ip` directly.

kerem commented

2026-03-15 22:16:08 +03:00

Author

Owner

@cssivision commented on GitHub (Sep 23, 2017):

for example:

// variable `host` may be a `domain` or `ip addr`.
let look_up = resolver.lookup_ip(&host);
let pair = look_up
            .and_then(move |res| if let Some(addr) = res.iter().next() {
                future::ok(addr)
            } else {
                // this logic is annoying
                if let Ok(addr) = IpAddr::from_str(&host) {
                    future::ok(addr)
                } else {
                    future::err(io::Error::new(io::ErrorKind::Other, "invalid addr".to_string()))
                }
            })
            .and_then(move |addr| {
                TcpStream::connect(&SocketAddr::new(addr, port), &handle1).map(|c2| (c1, c2))
            });

@cssivision commented on GitHub (Sep 23, 2017): for example: ```rust // variable `host` may be a `domain` or `ip addr`. let look_up = resolver.lookup_ip(&host); let pair = look_up .and_then(move |res| if let Some(addr) = res.iter().next() { future::ok(addr) } else { // this logic is annoying if let Ok(addr) = IpAddr::from_str(&host) { future::ok(addr) } else { future::err(io::Error::new(io::ErrorKind::Other, "invalid addr".to_string())) } }) .and_then(move |addr| { TcpStream::connect(&SocketAddr::new(addr, port), &handle1).map(|c2| (c1, c2)) }); ```

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Sep 24, 2017):

Ok. This makes sense. If you're still interested in putting that PR together, that would be awesome!

@bluejekyll commented on GitHub (Sep 24, 2017): Ok. This makes sense. If you're still interested in putting that PR together, that would be awesome!

kerem commented

2026-03-15 22:16:18 +03:00

Author

Owner

@cssivision commented on GitHub (Sep 24, 2017):

ok, i will spend some time on this.

@cssivision commented on GitHub (Sep 24, 2017): ok, i will spend some time on this.

kerem commented

2026-03-15 22:16:23 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 27, 2017):