James Kehr here with the Windows networking support team. This article covers details about mDNS and recommended best practices when trying to control the protocol designed to make life easier.
What is mDNS?
Starting with Windows 10 1703 Microsoft has included native support for multicast DNS, or mDNS. The protocol was developed by Apple, via RFC 6762 and RFC 6763, as a method to perform local network name and service discovery without the need for central name resolution, such as a DNS Server, and without user interaction. Simply put, it is how Apple made AirPlay2-based services perform seamless setup via the Bonjour service.
mDNS worked so well for Apple that it subsequently became the most popular many-to-many network name resolver because it uses regular old DNS over regular old IP multicast. This makes creating mDNS resolvers extremely easy as there are tons of DNS engines out there, and all major operating systems have mature multicast capabilities.
Just about everything uses mDNS these days. Seriously… everything. Pop open Wireshark on your home computer, set the capture filter to “udp port 5353”, which is the mDNS protocol (UDP) and port (5353), start the capture, then wait.
Devices and services from Microsoft, Apple, Google, and Amazon all use mDNS in some capacity. SmartTVs, Miracast (wireless screen mirroring), printers, set top boxes, wireless speakers, operating systems, and more all use mDNS. Most use it to resolve service records for device discovery. Others to resolve network names. Some do both. Our modern connected life wouldn’t be the same without mDNS.
mDNS is everywhere these days because it is a simple, easy to build, user friendly – as in users do not need to know or do anything with mDNS for it to “just work” – network discovery protocol. Everyone in the tech industry loves mDNS, whether they know the protocol exists or not … except corporate security.
mDNS in the Enterprise
Corporate security folks, in general, distrust anything that involves decentralized name resolution and multicast/broadcast in the same sentence. This includes mDNS because it is possible to poison name and service resolution with a cleverly written malicious script or program. Granted, a malicious mDNS resolver must first be on your network to do so and that, by itself, is a different kind of nightmare.
There is a magic registry value in Windows that will disable mDNS in the Windows DNS client resolver. I am not going to tell you what it is, but I will tell you why you should not rely on it to disable mDNS.
I mentioned that mDNS is easy to implement in the introduction of this article. In fact, it is so easy to implement that any given operating system, Windows included, could have multiple mDNS resolvers running at the same time. Chromium-based browsers (Chrome, Edge, etc.) have an mDNS resolver. Microsoft Teams has been known to use mDNS. Third-party apps and services can contain their own resolver. Oh, and those malicious programs can run their own mDNS resolver, too.
How is this possible?
Because mDNS uses the connectionless UDP protocol, and not TCP, you can have multiple listeners on UDP port 5353. I have a PowerShell command I use to demonstrate this, with sample output.
Get-NetUDPEndpoint -LocalPort 5353 | Select-Object LocalAddress,LocalPort,OwningProcess,@{ Name="ProcessName"; Expression={((Get-Process -Id $_.OwningProcess).Name )} }
Sample Output:
LocalAddress LocalPort OwningProcess ProcessName
------------ --------- ------------- -----------
:: 5353 18080 msedge
:: 5353 3592 svchost #DNSCache service, to confirm: tasklist /SVC /FI "PID eq <OwningProcess>"
0.0.0.0 5353 55708 Teams
0.0.0.0 5353 5512 chrome
0.0.0.0 5353 18080 msedge
Disabling mDNS via the registry will only remove one line from that output, the svchost where the DNSCache service lives. It will not stop other first- (Microsoft) and third-party (anyone else) mDNS resolvers. It will not stop devices on your network from reaching your Windows systems with mDNS. It honestly does not do a lot if your goal is to lock down mDNS on your corporate network.
What to do? What to do?
The Microsoft recommendation for locking down mDNS is to use Windows Defender Firewall. This is the best tool for the job and most corporations already manage the firewall through GPOs. This makes the lock down process a matter of modifying an existing well-known process.
Warning! Disabling mDNS can have unexpected negative consequences. Wireless screen sharing/mirroring in conference rooms may stop working. Accessing printers may break. Any number of other issues may creep up given broad service dependencies on mDNS.
Block Inbound
To completely lock down mDNS, disable the inbound “mDNS (UDP-In)” rules in Windows Defender Firewall for all profiles (Public, Private, and Domain). This will prevent all inbound mDNS traffic from being processed and effectively disable mDNS. This is not recommended for mobile workers who may need to use a device at home or client office that relies on mDNS for service discovery.
To disable mDNS within corporate offices only, disable mDNS (UDP-In) for just the Domain profile. This will allow mobile workers to connect at home and on the road, but not in your offices where there is domain connectivity. This is the recommended best practice for mobile workforces.
You can optionally disable mDNS (UDP-In) for the Public profile, too. This might interfere with Miracast screen sharing, which relies on the Public profile, and homes where the Private profile is not selected, but it does add an extra measure of security in public places, like a coffee shop.
What About Outbound?
We do not recommend blocking outbound unless your company needs the absolute strictest of network controls due to a high security requirement. Blocking inbound mDNS is sufficient for nearly all use cases.
mDNS plays a critical role in modern computing. It is not like previous multicast- and broadcast-based name resolution protocols, like LLMNR, SSDP, and NbtNS, which had limited adoption and usefulness. mDNS has near universal adoption within the tech industry which makes controlling it less cut and dry. Hopefully this article will make mDNS decision process a bit easier.
Microsoft
