What is Multicast DNS (mDNS) and how does it work?
Multicast DNS (mDNS) is a protocol used in network environments to resolve hostnames to IP addresses within small networks without the need for a dedicated DNS server.
It is particularly useful in local area networks (LANs), such as home or office networks, where devices need to discover and communicate with each other dynamically.
mDNS operates by using multicast packets over UDP (User Datagram Protocol) to send DNS queries to all devices on the local network, allowing them to respond with the appropriate IP addresses.
Introduction
Starting with Windows 10 1703 Microsoft has included native support for multicast DNS, or mDNS.
mDNS is not natively supported on Windows Server versions prior to Windows Server 2019. For Windows Server 2016 and earlier you can use third-party software to implement mDNS functionality.
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.
Source: https://techcommunity.microsoft.com/t5/networking-blog/mdns-in-the-enterprise/ba-p/3275777
Showing how mDNS works by using WireShark
Below I was sending some ICMP Echo Request Messages (Pings) from my W2K22-Testing-VM01 server which have the IP address 192.168.2.74, to the computer with the hostname Matrix-Veeam and which have the IP address 192.168.2.73.
On the W2K22-Testing-VM01 server there is no DNS server or WINS server configured which can be used to resolve the hostname into its IP address and besides there are also no DNS suffixes configured to append for the correct name resolution like shown in my following post. As you will see in this post, besides DNS and mDNS, on Windows Server 2022 there are also further methods like Link-Local Multicast Name Resolution (LLMNR) and NetBIOS over TCP/IP (NBT) available to resolve hostnames into IP addresses.
Nevertheless the hostname is resolved into its correct IP address which is 192.168.2.73. So this was just possible by using one of these other methods mentioned with Multicast Name Resolution (LLMNR), NetBIOS over TCP/IP (NBT) or mDNS.
On my W2K22-Testing-VM01 computer which is pinging the Matrix-Veeam computer I was starting a new Wireshark session and filtering for the mDNS protocol.
The first row will show the request (query) by the W2K22-Testing-VM01 (192.168.2.74) server for the hostname Matrix-Veeam.local. (192.168.2.73). The query packets are send to the mDNS multicast address 224.0.0.251 and UDP port 5353. This multicast IP address range is not routable!
By default, mDNS exclusively resolves hostnames ending with the .local top-level domain.
Source: https://en.wikipedia.org/wiki/Multicast_DNS
IP multicast packets are identified by using a destination address in a range from 224.0.0.0 to 224.0.0.255. The addresses within the range are reserved for specific purposes. For example, 224.0.0.1 means all nodes on the subnet, while 224.0.0.2 means all routers on the subnet. The address 224.0.0.251 is reserved for multicast DNS (mDNS), which is used to query devices for their capabilities.
Source: https://www.pcmag.com/encyclopedia/term/ip-multicast
The third row will show the mDNS answer packets to the previous multicast query by the Matrix-Veeam server with its IP address 192.168.2.73. So from now on the W2K22-Testing-VM01 server had resolved the hostname into its IP address by using mDNS and without using classic DNS.
The second row and query and the fourth row and answer are the same but just for IPv6.
Disable mDNS in Windows
We can disable mDNS by either adding a new registry value or by blocking the network traffic for mDNS on UDP port 5353.
Adding Registry value
Open the registry and navigate to the following Parameters key and add a new DWORD (32-bit) value named EnableMDNS and leave the value on 0 for disabling mDNS.
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Blocking UDP Port 5353 on Firewall
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.
Source: https://techcommunity.microsoft.com/t5/networking-blog/mdns-in-the-enterprise/ba-p/3275777
To determine if the computer is listening for incoming mDNS queries, we can execute the following commands in the PowerShell or by using the netstat tool also the CMD:
> Get-NetUDPEndpoint -LocalPort 5353 > netstat -nao | findstr "5353"
As mentioned, the OS could have multiple mDNS resolvers running at the same time because other applications running on the OS could have their own mDNS resolver like Chromium-based browsers (Chrome, Edge, etc.).
Because mDNS uses the connectionless UDP protocol, and not TCP, you can have multiple listeners on UDP port 5353. You can use the following PowerShell command which will also output the owing process. Below for example is the output from my Windows 11 computer.
> Get-NetUDPEndpoint -LocalPort 5353 | Select-Object LocalAddress,LocalPort,OwningProcess,@{ Name="ProcessName"; Expression={((Get-Process -Id $_.OwningProcess).Name )} }
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.
Below I will configure this by using group policies and apply them to all computers on which mDNS should be disabled.
Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security.
Add a new rule.
For the protocol select UDP and specify the UDP port 5353 for mDNS.
Select Block the connection.
We apply this rule for profiles.
More about configuring rules by using a group policy you will find in the following Microsoft article https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure.
Finally on all computers we linked this GPO from now on incoming UDP traffic on port 5353 will be blocked.
When now a computer is trying to resolve the hostname into its IP address by using mDNS queries, from the destination host no answer packets will shown up as previously when the firewall doesn’t block incoming queries on UDP port 5353.
Below we now just see the outbound mDNS queries.
Links
What is mDNS?
https://techcommunity.microsoft.com/t5/networking-blog/mdns-in-the-enterprise/ba-p/3275777Multicast DNS
https://en.wikipedia.org/wiki/Multicast_DNSIP multicast
https://en.wikipedia.org/wiki/IP_multicastMulticast address
https://en.wikipedia.org/wiki/Multicast_addressConfigure rules with group policy
https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure
