starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #1057] Replicating `hostname -d` #593

New issue

Open

opened 2026-03-15 23:21:09 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 23:21:09 +03:00

Owner

Originally created by @Diggsey on GitHub (Apr 4, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1057

I'm trying to replicate the behaviour of hostname -d.

From looking at the source for this command, it appears to first get the hostname of the computer, and then searches for A records for that hostname. The result of this search is a hostent containing the FQDN from which the domain part can be extracted.

When I run hostname -d in WSL I get localdomain. The equivalents on windows report either no domain or WORKGROUP. I would want to get something similar when I use trust-dns in the two environments.

This is my first attempt:

use trust_dns_resolver::Resolver;

fn main() {
    let resolver = Resolver::from_system_conf().unwrap();
    let hn = hostname::get().unwrap().into_string().unwrap();
    println!("{}", hn);
    let ip_lookup = resolver.lookup_ip(&hn).unwrap();
    for ip in ip_lookup {
        println!("{}", ip);
        let res = resolver.reverse_lookup(ip).unwrap();
        for x in res {
            println!("{}", x);
        }
    }
}

However, when I run this on windows, I get:

DESKTOP-SBVU0O9
<long pause>
[Random IP address seemingly belonging to my ISP]
<long pause>
unallocated.barefruit.co.uk.

If I run it in WSL, it completes instantly but I get this:

DESKTOP-SBVU0O9
127.0.1.1
localhost.

Now, the windows results I'm not too fussed about - there's not a clear equivalent to hostname -d, although I would like it to not take 30 seconds, and not give something completely crazy like that. However, I believe my ISP is mostly to blame as it seems to be spoofing DNS results in order to direct me to adverts when the domain doesn't exist...

However, the WSL results are confusing to me. My /etc/hosts file (in WSL) looks like this:

# This file is automatically generated by WSL based on the Windows hosts file:
# %WINDIR%\System32\drivers\etc\hosts. Modifications to this file will be overwritten.
127.0.0.1       localhost
127.0.1.1       DESKTOP-SBVU0O9.localdomain     DESKTOP-SBVU0O9

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

So it seems pretty clear to me that the IP 127.0.1.1 should correspond to the FQDN DESKTOP-SBVU0O9.localdomain, from which I could correctly determine the domain name, and yet trust-dns is still returning localhost?

Originally created by @Diggsey on GitHub (Apr 4, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1057 I'm trying to replicate the behaviour of `hostname -d`. From looking at the source for this command, it appears to first get the hostname of the computer, and then searches for A records for that hostname. The result of this search is a `hostent` containing the FQDN from which the domain part can be extracted. When I run `hostname -d` in WSL I get `localdomain`. The equivalents on windows report either no domain or WORKGROUP. I would want to get something similar when I use trust-dns in the two environments. This is my first attempt: ```rust use trust_dns_resolver::Resolver; fn main() { let resolver = Resolver::from_system_conf().unwrap(); let hn = hostname::get().unwrap().into_string().unwrap(); println!("{}", hn); let ip_lookup = resolver.lookup_ip(&hn).unwrap(); for ip in ip_lookup { println!("{}", ip); let res = resolver.reverse_lookup(ip).unwrap(); for x in res { println!("{}", x); } } } ``` However, when I run this on windows, I get: ``` DESKTOP-SBVU0O9 <long pause> [Random IP address seemingly belonging to my ISP] <long pause> unallocated.barefruit.co.uk. ``` If I run it in WSL, it completes instantly but I get this: ``` DESKTOP-SBVU0O9 127.0.1.1 localhost. ``` Now, the windows results I'm not too fussed about - there's not a clear equivalent to `hostname -d`, although I would like it to not take 30 seconds, and not give something completely crazy like that. However, I believe my ISP is mostly to blame as it seems to be spoofing DNS results in order to direct me to adverts when the domain doesn't exist... However, the WSL results are confusing to me. My `/etc/hosts` file (in WSL) looks like this: ``` # This file is automatically generated by WSL based on the Windows hosts file: # %WINDIR%\System32\drivers\etc\hosts. Modifications to this file will be overwritten. 127.0.0.1 localhost 127.0.1.1 DESKTOP-SBVU0O9.localdomain DESKTOP-SBVU0O9 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ``` So it seems pretty clear to me that the IP 127.0.1.1 should correspond to the FQDN `DESKTOP-SBVU0O9.localdomain`, from which I could correctly determine the domain name, and yet trust-dns is still returning `localhost`?

kerem added the

enhance

crate:resolver

question

labels

2026-03-15 23:21:09 +03:00

kerem commented

2026-03-15 23:21:20 +03:00

Author

Owner

@Diggsey commented on GitHub (Apr 4, 2020):

I've tried doing the same thing with getaddrinfo and getnameinfo, and they work as expected on both windows and WSL.

There are three parts of trust-dns that are not working as expected:

On windows, lookup_ip produces a different result from getaddrinfo with the same hostname.
On windows, reverse_lookup finds no records for my LAN IP where getnameinfo correctly returns DESKTOP-SBVU0O9.
On WSL, reverse_lookup does not use the /etc/hosts file and somehow resolves the IP to localhost when getnameinfo instead resolves it to DESKTOP-SBVU0O9.localdomain.

@Diggsey commented on GitHub (Apr 4, 2020): I've tried doing the same thing with `getaddrinfo` and `getnameinfo`, and they work as expected on both windows and WSL. There are three parts of trust-dns that are not working as expected: - On windows, `lookup_ip` produces a different result from `getaddrinfo` with the same hostname. - On windows, `reverse_lookup` finds no records for my LAN IP where `getnameinfo` correctly returns `DESKTOP-SBVU0O9`. - On WSL, `reverse_lookup` does not use the `/etc/hosts` file and somehow resolves the IP to `localhost` when `getnameinfo` instead resolves it to `DESKTOP-SBVU0O9.localdomain`.

kerem commented

2026-03-15 23:21:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 5, 2020):

On linux/wsl, could you show what's in your /etc/resolv.conf?

@bluejekyll commented on GitHub (Apr 5, 2020): On linux/wsl, could you show what's in your `/etc/resolv.conf`?

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Apr 5, 2020):

FYI, I just reviewed the code quickly. I'm fairly certain we don't currently evaluate the hosts file for reverse mappings today. The reason you're getting localhost for the reverse of the 127.0.1.1 is that there is a static rule to bind 127/8 to localhost, that happens here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/lookup_state.rs#L133.

I think if we want to support reverse mappings from the hosts file, it might be as simple as adding the logic with the reverse mapping here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/hosts.rs#L42. This would need a reverse mapping stored as well, right now there is by_name, so we'd need a by_ip as well.

In addition to that, the hosts file is only referenced in the lookup_ip methods. So we'd want to consider adding that to all lookups, possibly, it would need to be queried here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/lookup.rs#L244

I think that would address the issue you're asking about.

@bluejekyll commented on GitHub (Apr 5, 2020): FYI, I just reviewed the code quickly. I'm fairly certain we don't currently evaluate the `hosts` file for reverse mappings today. The reason you're getting `localhost` for the reverse of the `127.0.1.1` is that there is a static rule to bind `127/8` to localhost, that happens here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/lookup_state.rs#L133. I think if we want to support reverse mappings from the hosts file, it might be as simple as adding the logic with the reverse mapping here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/hosts.rs#L42. This would need a reverse mapping stored as well, right now there is `by_name`, so we'd need a `by_ip` as well. In addition to that, the hosts file is only referenced in the lookup_ip methods. So we'd want to consider adding that to all lookups, possibly, it would need to be queried here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/lookup.rs#L244 I think that would address the issue you're asking about.

kerem commented

2026-03-15 23:21:35 +03:00

Author

Owner

@Diggsey commented on GitHub (Apr 5, 2020):

Yeah, that sounds like it would fix the WSL problem. I could put in a PR to support the reverse mapping, but I'm not exactly sure what would need doing to support the other lookups you mentioned.

I think it's still a little weird that getaddrinfo on windows returns the expected IP for DESKTOP-SBVU0O9 - it must be doing something other than a DNS lookup...

One other thing: it seems like it should be possible to go from a hostname to a FQDN without having to do the additional reverse search? I'm really only interested in the specific result for the hostname, and it seems like going back via the IP could potentially return other results?

@Diggsey commented on GitHub (Apr 5, 2020): Yeah, that sounds like it would fix the WSL problem. I could put in a PR to support the reverse mapping, but I'm not exactly sure what would need doing to support the other lookups you mentioned. I think it's still a little weird that `getaddrinfo` on windows returns the expected IP for `DESKTOP-SBVU0O9` - it must be doing something other than a DNS lookup... One other thing: it seems like it should be possible to go from a hostname to a FQDN without having to do the additional reverse search? I'm really only interested in the specific result for the hostname, and it seems like going back via the IP could potentially return other results?

kerem commented

2026-03-15 23:21:40 +03:00

Author

Owner

@JessicaBlunt commented on GitHub (Apr 23, 2020):

I came across this on my system, but I don't even have trust-dns installed. Sorry if this is silly - I don't have a strong networking background.

nmap address                                                                                                                                                                                                          Starting Nmap 7.60 ( https://nmap.org ) at 2020-04-23 01:28 CDT                                                         Nmap scan report for address (92.242.140.2)                                                                             
Host is up (0.13s latency).                                                                                             
rDNS record for 92.242.140.2: unallocated.barefruit.co.uk                                                               
Not shown: 999 filtered ports                                                                                           
PORT   STATE SERVICE                                                                                                    
80/tcp open  http                                                                                                                                                                                                                               Nmap done: 1 IP address (1 host up) scanned in 10.15 seconds

Could this be a WSL issue? If someone here thinks so, I'll try to report it to Microsoft.

@JessicaBlunt commented on GitHub (Apr 23, 2020): I came across this on my system, but I don't even have trust-dns installed. Sorry if this is silly - I don't have a strong networking background. ``` nmap address Starting Nmap 7.60 ( https://nmap.org ) at 2020-04-23 01:28 CDT Nmap scan report for address (92.242.140.2) Host is up (0.13s latency). rDNS record for 92.242.140.2: unallocated.barefruit.co.uk Not shown: 999 filtered ports PORT STATE SERVICE 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 10.15 seconds ``` Could this be a WSL issue? If someone here thinks so, I'll try to report it to Microsoft.

kerem referenced this issue

2026-03-16 02:12:11 +03:00

[PR #593] [MERGED] Make trust_dns_server::server::ResponseHandler Send #1545