Greater device interoperability with Macs and Linux system on the horizon for Windows 10. Operating system finally acknowledges it is not alone in having a widely deployed network‐discoverability protocol.
DNS‐SD is now used by Windows 10 and Windows 10 Mobile natively when looking for nearby network printers. Microsoft has only documented the feature for Mobile, but it works in the other Windows 10 editions.
Windows still doesn’t support mDNS everywhere, even though it may seem like it in many cases. Windows will special‐case domains ending in the .local TLD and also do a sneaky NetBIOS Name Service (NBNS or WINS) and a Link‐Local Multicast Name Resolution (LLMNR) look‐up of the domain without the TLD. Which will make it seem like .local domains work in many cases where the remote client also have one of the competing protocol services configured. Yet, Windows can resolve mDNS domains perfectly fine when used with the printer discovery feature. (It might take two attempts, because it’s quite buggy still.) So the foundations for mDNS in Windows are definitively being added.
The end result of this inconsistent support is that you may or may not be able to reach other machines from programs, games, and web browsers by typing in their mDNS address (for example MacBook.local). This is not a great experience for users, but by the looks of it this could be addressed in a future update to the operating system.
There are other signs throughout Windows about greater support for mDNS being added to to Windows in the near future. In the latest Windows Insider build, a new new default firewall rule called “mDNS (UDP‐In)” have been added. There are also several more mentions of DNS‐SD and mDNS throughout Windows core libraries than there were in the final Windows 10 release.
The latest Windows Insider build also resolves the DNS‐SD bug that plagued system and network administrators after the release of Windows 10. Whenever Windows would query the local network for devices, it would immediately answer it’s own query with a zero‐answer reply. Essentially, Windows would send one request asking “Does anyone offer this service?” and then immediately answer “I don’t, nor know of anyone who does”. The most popular DNS‐SD implementation on Linux, Avahi, had to filter out these invalid messages from their logs as the volume of the log messages caused problems in larger networks.
Windows own built‐in consumer‐level sharing features (Homegroup) are not announced over DNS‐SD at this time. However, I have faith in Microsoft on this one and expect to see it in a future release.
Microsoft’s developer and network administration outreach so far has been limited to detailing the WinJS API for use with apps and one video on Channel 9. Printer announcements have also been documented.
All DNS‐SD APIs and functionality is entirely disabled if you’re running a machine with a Hyper‐V kernel and route traffic through a Network Virtualized Switch. The other network discovery protocols deployed by Windows NBNS, LLMNR, and SSDP all still work even though DNS‐SD is made unavailable. A very peculiar limitation, however, the Settings app: Network: Ethernet is also entirely broken in this scenario, so the newer Windows APIs may not entirely understand a switched interface from a virtualization host’s perspective.