dig / nslookup cannot resolve, but ping can

Question

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)

Answer 1

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).

Answer 2

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:\Users\Me>hostname DESKTOP-UJTKQ4C

C:\Users\Me>nslookup DESKTOP-UJTKQ4C Server: UnKnown Address: 192.168.231.1

*** UnKnown can't find DESKTOP-UJTKQ4C: Non-existent domain