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
$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
$ 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
$ nslookup minwinpc.local
Server: 172.20.10.1
Address: 172.20.10.1#53
** server can't find minwinpc.local: NXDOMAIN
Related questions:
- https://stackoverflow.com/questions/45616546
- MSDN forums (same question)
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:
C:UsersMe>hostname
DESKTOP-UJTKQ4C
C:UsersMe>nslookup DESKTOP-UJTKQ4C
Server: UnKnown
Address: 192.168.231.1
*** 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. dig
and nslookup
by contrast may only understand or use the traditional DNS protocol, which knows nothing about mDNS, and thus fail.
The .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).