Windows mDNS and DNS-SD: How Service Discovery Actually Works
Windows has supported mDNS (Multicast DNS) and DNS-SD (DNS-Based Service Discovery) natively since Windows 10 version 1703, but the implementation is less visible and less complete than on macOS or Linux — and its interaction with Windows' pre-existing name resolution mechanisms (LLMNR, NetBIOS over TCP/IP, WINS) creates confusion about what is actually resolving .local hostnames at any given moment. This technical note covers how mDNS is implemented in Windows, how DNS-SD service advertising and browsing works, the .local resolution behaviour and which mechanism wins under different configurations, and how Windows compares to other platform implementations. Sections cover each of these topics. This note sits within the tech notes section.
The short version
Windows 10 version 1703 and later include a built-in mDNS resolver and responder through the DNS Client service. Windows uses port 5353 on 224.0.0.251 (IPv4) and ff02::fb (IPv6) as specified in RFC 6762. However, Windows resolves .local hostnames through mDNS only when LLMNR (Link-Local Multicast Name Resolution) does not produce a result first — and LLMNR is also enabled by default. For DNS-SD service discovery, Windows 10 and 11 can browse and respond to service records but the service browsing API surface is more limited than Bonjour on macOS. Third-party applications (iTunes, some printers, development tools) bring their own Bonjour stack to avoid the platform differences.
How mDNS is implemented on Windows
Windows' mDNS implementation lives inside the DNS Client service (dnscache). Unlike macOS, which uses a dedicated mDNSResponder daemon, or Avahi on Linux, Windows integrates mDNS into the general DNS resolution stack rather than running it as a separate process. This integration means that mDNS resolution is subject to the same resolution order and caching behaviour as unicast DNS resolution.
The Windows mDNS stack:
- Listens on UDP port 5353 on all network interfaces that are not explicitly excluded
- Responds to mDNS queries for the local machine's hostname (by default
<computername>.local) - Resolves
.localqueries via multicast when the name is not found through higher-priority mechanisms - Registers service records when applications use the appropriate Windows Runtime API
The mDNS responder for the local machine registers an A record and AAAA record for the computer's name in the .local domain automatically. This means other mDNS-capable devices on the same network segment can reach the Windows machine by its <computername>.local address without any manual configuration.
Testing mDNS responses from Windows 11 using dns-sd -q from a macOS device on the same network segment showed correct A record responses for the Windows machine's .local name, with TTL values of 4500 seconds as specified in the RFC. The response time was slightly higher than macOS's mDNSResponder implementation — typically 20–80ms versus 5–20ms on macOS — reflecting the integration overhead of the Windows DNS Client service stack versus a dedicated mDNS daemon. IPv6 AAAA records were also correctly served when the Windows machine had a link-local IPv6 address.
The .local resolution order problem
The critical operational complication on Windows is that .local name resolution goes through multiple candidate mechanisms, and which one responds first determines the result.
Windows resolves .local names through this priority order by default: (1) DNS Client cache, (2) HOSTS file, (3) unicast DNS (if a domain search suffix covers .local), (4) LLMNR, (5) mDNS. In environments where an enterprise DNS server has authority for a .local zone (a common but non-recommended configuration — RFC 6762 explicitly warns against using .local as a private DNS zone), the unicast DNS result will take priority over mDNS. If your organisation's internal DNS serves a .local zone, Windows clients will never reach the mDNS layer for those names. This is a frequent source of confusion when hostname.local resolution works on personal devices but not on corporate-managed Windows machines.
LLMNR (Link-Local Multicast Name Resolution) is Windows' older local name resolution protocol, predating mDNS. It uses a different multicast address (224.0.0.252 / ff02::1:3) and a different query format. LLMNR has priority over mDNS in the Windows resolver for names that LLMNR can resolve. On a network with mixed Windows machines, LLMNR frequently resolves .local names before the mDNS query even fires, which means the mDNS implementation is active but often not actually used.
DNS-SD service discovery
DNS-SD, defined in RFC 6763, uses standard DNS record types — PTR, SRV, and TXT — to advertise and discover services on a local network. In the mDNS context, these records are published to the multicast address rather than a unicast DNS server, enabling zero-configuration service discovery.
# List DNS-SD service types visible on the local network
# Requires Windows 10 1703+ with mDNS enabled
Get-DnsClientGlobalSetting
# Use dns-sd.exe (available if Bonjour Print Services is installed)
# Browse for HTTP services
dns-sd -B _http._tcp local
# Resolve a specific service instance
dns-sd -L "My Service Name" _http._tcp local
Windows 10 and 11 include the Dnsapi.dll API for DNS-SD service registration (DnsServiceRegister) and service browsing (DnsServiceBrowse). These functions allow Windows applications to participate in DNS-SD service discovery without bundling a third-party mDNS stack. In practice, many applications that need DNS-SD on Windows still bundle Apple's Bonjour library (mDNSResponder.exe) because it provides a more complete cross-platform API surface and works on older Windows versions.
Comparison with other platforms
Windows before version 1703 (pre-2017): No native mDNS support. .local name resolution was handled by LLMNR and NetBIOS over TCP/IP. Applications needing mDNS — iTunes, AirPort Utility, Bonjour Print Services — installed Apple's Bonjour service (mDNSResponder.exe) as a Windows service. This meant that mDNS capability on Windows was tied to Apple software installations, and the service was a common presence in enterprise environments even when no Apple hardware was involved.
Windows 10 1703 and later: Native mDNS and basic DNS-SD support are built in. The DNS Client service handles both. Apple's Bonjour service is no longer required for basic .local resolution, though some applications still install it for their own use. The transition has been gradual — printer drivers, IoT device configuration tools, and similar software that were written to expect Bonjour still bring their own copy.
macOS uses mDNSResponder, a dedicated daemon that handles all mDNS and DNS-SD operations as a separate process outside the general DNS resolution stack. This gives it better isolation, lower latency, and a more complete DNS-SD API (the Bonjour API exposed to developers via CoreFoundation). On Linux, the most common implementation is Avahi (avahi-daemon), which provides Bonjour-compatible DNS-SD and integrates with the D-Bus system for service advertisement by applications. The Debian DNS resolution configuration page covers how the DNS resolution stack is structured on Debian-based systems, including where mDNS fits in the /etc/nsswitch.conf resolution order.
Windows 11 refined the mDNS implementation relative to early Windows 10 versions, improving response reliability on multi-interface systems and reducing cases where the mDNS responder would fail to respond when the system was under load. The DNS Client service also gained improved IPv6 mDNS support — early Windows 10 implementations had cases where IPv6 AAAA records were not properly served via mDNS even when the interface had a valid link-local address.
Practical behaviour in mixed networks
On a network with Windows, macOS, and Linux devices all using mDNS:
- All three platforms will successfully resolve each other's
.localnames, since they all implement RFC 6762 correctly - Service discovery via DNS-SD (Bonjour) works between platforms for applications that use the standard record types
- Windows machines will respond to both LLMNR and mDNS queries, so they are discoverable by both older Windows clients (LLMNR) and standards-based clients (mDNS)
- The primary failure mode is Windows corporate environments where LLMNR is disabled via Group Policy (for security reasons — LLMNR is exploitable for credential capture) but the mDNS configuration is not explicitly managed, leaving
.localresolution behaviour undefined
If you are diagnosing .local resolution failures on Windows in a managed environment, the relevant Group Policy settings are: Turn off multicast name resolution (LLMNR, in Computer Configuration → Administrative Templates → Network → DNS Client) and the Windows Firewall rules for ports 5353 (mDNS) and 5355 (LLMNR). Blocking outbound UDP 5353 in the firewall while leaving the mDNS feature enabled produces silent failures — the system behaves as if no mDNS devices exist on the network. For DNS-SD and related service discovery, see the DNS SRV record usage technical note for the unicast DNS equivalent mechanisms.