Greater device interoperability with Macs and Linux system on the horizon for Windows 10. The operating system finally acknowledges it isn’t alone in having a widely deployed network-discoverability protocol.
Domain Name System Service Discovery (DNS-SD) is the service announcement and discovery protocol of Multicast-DNS (mDNS). Windows 10 and Windows 10 Mobile natively use mDNS and DNS-SD 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 Top-Level Domain (TLD) and also do a sneaky NetBIOS Name Service (NBNS) (sometimes known as 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 has 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 isn’t 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 Windows in the near future. In the latest Windows Insider build, a new default firewall rule called “mDNS (UDP-In)” has 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 its 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) aren’t announced over DNS-SD at this time. However, I’ve faith in Microsoft on this one and expect to see it in a future release.
Microsoft’s developer and network administration outreach so far have 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 are 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.
Update (): The optional ‘Device discovery’ setting, part of Developer mode, now uses mDNS to announce the device on the network. It’ unclear whether this will be on by default outside of developer mode at a later time.
Update (): Windows 10 also uses DNS-SD to announce and discover wireless displays (Wi-Fi Direct/P2P/Miracast) on the local network.