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 ( 56 data bytes
64 bytes from icmp_seq=0 ttl=128 time=6.539 ms


$ dig minwinpc.local any @

; <<>> DiG 9.8.3-P1 <<>> minwinpc.local any @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61796
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;minwinpc.local.        IN  ANY

;; Query time: 51 msec
;; WHEN: ...
;; MSG SIZE  rcvd: 35


$ nslookup minwinpc.local

** server can't find minwinpc.local: NXDOMAIN

Related questions:

Asked By: Etan


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>nslookup DESKTOP-UJTKQ4C
Server: UnKnown

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

Answered By: Raymond Bannan

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

Answered By: thrig
Categories: Answers Tags: , , , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.