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:

  • Thanks, I tried dns-sd -q minwinpc.local and that works. Does the iPhone create this mDNS entry? I doubt that the Win 10 IoT board creates it itself. Also, please re-create your comment as an answer so it can be accepted.
    – Etan
    Aug 10, 2017 at 15:20

2 Answers 2


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


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:

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


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .