dig / nslookup cannot resolve, but ping can
I’m experimenting with a Win10 IoT board that runs a web interface on minwinpc.local. This works fine in the browser, and also when I use ping.
However, when I use dig or nslookup, I cannot get resolve working.
How can ping and the browser possibly get the IP if the more basic tools fail to do the resolve?
Setup is just a DragonBoard with Win10 IoT Core, connected to an iPhone hotspot. Client that tries connecting is running macOS Sierra. No special hosts or resolve files have been adjusted.
$ping minwinpc.local PING minwinpc.local (172.20.10.3): 56 data bytes 64 bytes from 172.20.10.3: icmp_seq=0 ttl=128 time=6.539 ms
$ dig minwinpc.local any @172.20.10.1 ; <<>> DiG 9.8.3-P1 <<>> minwinpc.local any @172.20.10.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61796 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;minwinpc.local. IN ANY ;; Query time: 51 msec ;; SERVER: 172.20.10.1#53(172.20.10.1) ;; WHEN: ... ;; MSG SIZE rcvd: 35
$ nslookup minwinpc.local Server: 172.20.10.1 Address: 172.20.10.1#53 ** server can't find minwinpc.local: NXDOMAIN
dig and nslookup are going to ignore the hosts file, they want to resolve via asking the primary DNS server. Ping and your browser on the other hand will use the hosts file, and so it looks like that’s the reason dig and nslookup can’t resolve.
The following is done from my win10 laptop:
*** UnKnown can’t find DESKTOP-UJTKQ4C: Non-existent domain
This is not a problem of a more basic protocol not working, but rather that there are multiple name service resolution protocols being used;
ping here understands multicast DNS (mDNS) and is able to resolve the name
minwinpc.local to an IP address via that protocol.
nslookup by contrast may only understand or use the traditional DNS protocol, which knows nothing about mDNS, and thus fail.
.local domain is a clear indicator of mDNS (via a web search on ".local domain"); more can be read about it in [RFC 6762]. Another option for debugging a situation like this would be to run
tcpdump or WireShark and look for packets that contain
minwinpc.local; this may reveal the mDNS traffic.
Still another option would be to
nmap the IP of the
minwinpc.local device; this may well show that the device is listening on UDP/5353 and then one can research what services that port is used for (and then one could
sudo tcpdump udp port 5353 to inspect what traffic involves that port).