mDNS Detection (Remote Network): How to Block UDP 5353 and Fix Nessus 12218

mDNS Detection (Remote Network) is a Nessus finding (plugin 12218) raised when a host answers multicast DNS queries on UDP 5353 from a scanner on a different subnet, exposing its hostname, services and sometimes OS details. Fix it by filtering UDP 5353 at routed boundaries, disabling Avahi or Bonjour where unused, then rescanning from another subnet.

mDNS (the protocol behind Bonjour, Avahi and zeroconf) is meant to stay on the local link. When a scanner two routers away gets an answer, something is either ignoring that rule or forwarding traffic it should not.

What the scanner is actually detecting

Tenable has two plugins for this protocol; the difference is where the scanner sits.

Both are remote, unauthenticated checks in the Service detection family, and both carry the same solution text from Tenable: filter incoming traffic to UDP port 5353, if desired. Read the plugin output to see what the responder returned; it is the fastest way to judge how much the host is leaking.

Why the remote case matters: RFC 6762 section 5.5 says a responder that receives a direct unicast query SHOULD check that the source address belongs to the local subnet (or, for IPv6, has an on-link prefix) and silently ignore it otherwise. A 12218 hit means that check did not happen, or a gateway relayed the query onto the segment.

Real-world risk, stated honestly

This is an information disclosure and reconnaissance issue, not a remote code execution bug. Tenable’s description says the protocol can reveal the operating system type and version, the hostname and the list of running services. For an attacker already inside another VLAN, that is a cheap map of printers, file shares and workstations.

CERT/CC vulnerability note VU#550620 covers the same behavior (mDNS responders answering unicast queries from outside the local link) and names two impacts: disclosure of device information such as model and OS, and use in denial of service amplification, because responses are larger than queries. The amplification risk matters most when UDP 5353 is reachable from the internet. On a purely internal routed network, the realistic impact is reconnaissance.

CVE-2017-6519 describes avahi-daemon through 0.6.32 and 0.7 responding to IPv6 unicast queries from off-link sources. If a Linux host is flagged only over IPv6, check the Avahi package version as well as the firewall.

How to confirm it on the host

Start from the same vantage point as the scanner, a machine on a different subnet, and query the target directly. The first command asks for the DNS-SD service type list defined in RFC 6763:

dig @192.0.2.10 -p 5353 -t PTR _services._dns-sd._udp.local
nmap -sU -p 5353 --script dns-service-discovery 192.0.2.10

Any answer from a remote subnet reproduces the finding. Then identify the listener on the host itself.

Linux:

sudo ss -ulpn | grep 5353
systemctl status avahi-daemon.service avahi-daemon.socket
resolvectl status | grep -i mdns

systemd-resolved can also run an mDNS responder; resolvectl status shows +mDNS or -mDNS per link.

Windows (Windows 10 1703 and later include an mDNS resolver in the DNS Client service):

Get-NetUDPEndpoint -LocalPort 5353 |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{Name='ProcessName'; Expression={(Get-Process -Id $_.OwningProcess).Name}}

Get-NetFirewallRule -Name 'MDNS-In-UDP-*' |
    Select-Object Name, Profile, Enabled,
        @{n='RemoteAddress'; e={($_ | Get-NetFirewallAddressFilter).RemoteAddress}}

Look at the RemoteAddress column. On the Windows 11 machine we checked, the Domain profile rule accepted Any source while the Private and Public rules were limited to LocalSubnet. That is a likely reason domain-joined PCs answer across subnets.

macOS:

sudo lsof -nP -iUDP:5353
defaults read /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements

Printers and appliances: open the embedded web server and look for a Bonjour, mDNS or AirPrint setting in the network protocol section.

How to fix it

At the network boundary (fixes plugin 12218 for every device behind it)

CERT’s guidance is to block inbound and outbound mDNS on the WAN and, where it is not needed, to stop UDP 5353 from entering or leaving the local link. In practice: add a deny rule for UDP 5353 on the router or firewall ACLs between VLANs and at the internet edge. Same-segment discovery keeps working because legitimate mDNS never needs to cross a router.

Before you do, check for anything deliberately relaying mDNS between segments: an Avahi host with enable-reflector=yes, or an mDNS gateway feature on a wireless controller or router. If you need one, scope it to the specific services and VLANs that require it rather than reflecting everything.

Linux servers: disable Avahi

Servers rarely need service discovery. The CIS benchmarks recommend stopping both units and then removing the package or masking the units:

sudo systemctl disable --now avahi-daemon.socket avahi-daemon.service
sudo systemctl mask avahi-daemon.socket avahi-daemon.service

Disable the socket as well as the service, otherwise socket activation can start the daemon again. On Debian and Ubuntu, sudo apt purge avahi-daemon removes it entirely; review which packages depend on it first.

If the host genuinely needs Avahi (a desktop, a print server), restrict it in /etc/avahi/avahi-daemon.conf and restart the daemon:

[server]
allow-interfaces=eth0

[publish]
publish-hinfo=no
publish-workstation=no

[reflector]
enable-reflector=no

Pair this with a host firewall rule so off-subnet unicast queries never reach the daemon. With firewalld, check what the mdns service admits; current firewalld releases limit it to the multicast group addresses 224.0.0.251 and ff02::fb:

sudo firewall-cmd --info-service=mdns

With plain iptables, drop UDP 5353 from anything outside the local subnet (adapt to your own ruleset and repeat for IPv6):

sudo iptables -I INPUT -p udp --dport 5353 ! -s 192.0.2.0/24 -j DROP

Linux: systemd-resolved

If resolvectl status showed +mDNS, set this in /etc/systemd/resolved.conf, then run sudo systemctl restart systemd-resolved:

[Resolve]
MulticastDNS=no

Use MulticastDNS=resolve instead if the host should still resolve .local names but stop responding.

Windows: use Windows Defender Firewall

Microsoft’s Windows networking team recommends controlling mDNS with the firewall rather than the registry switch that turns off mDNS in the DNS Client, because Chromium browsers, Teams and third-party apps run their own listeners on UDP 5353. Two options per host:

# Keep mDNS on the local segment only (closest match to plugin 12218)
Set-NetFirewallRule -Name 'MDNS-In-UDP-Domain-Active' -RemoteAddress LocalSubnet

# Or turn inbound mDNS off on the Domain profile entirely
Disable-NetFirewallRule -Name 'MDNS-In-UDP-Domain-Active'

Disabling the Domain profile rule is the practice Microsoft describes for corporate offices, because laptops still get mDNS at home on the Private profile. For a fleet, create an inbound Block rule for UDP 5353 on the Domain profile under Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules. Microsoft Learn documents that explicit block rules take precedence over conflicting allow rules, so this overrides the local allow rule.

macOS

The CIS macOS benchmark disables Bonjour advertising with:

sudo /usr/bin/defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool true

Reboot to apply. For managed Macs, deploy a configuration profile with PayloadType com.apple.mDNSResponder and the key NoMulticastAdvertisements. This stops the Mac advertising its services; it is not a substitute for the boundary filter.

Printers and embedded devices

Turn off Bonjour or mDNS in the device’s web interface if nobody discovers it that way. If AirPrint users depend on it, leave it on and rely on the boundary filter. Be careful when rescanning embedded gear, as covered in our guide to scanning fragile OT and embedded devices.

How to verify the fix and rescan

1. From a machine on another subnet, rerun the dig and nmap commands. dig should get no answer, and nmap should report the port as closed or open|filtered with no script output.
2. On Linux, confirm systemctl is-enabled avahi-daemon.socket avahi-daemon.service returns masked or disabled. On Windows, rerun the Get-NetFirewallRule query.
3. Rescan with Nessus from the same remote scanner. Plugin 12218 should no longer appear. This is a network-level check, so credentials do not change the result (see credentialed vs uncredentialed scanning).

What can break and how to roll back

• Printer discovery and AirPrint for clients that relied on mDNS.
• Screen mirroring and casting (AirPlay, Miracast, Chromecast-style devices), including conference room displays.
• AirDrop receiving on Macs with advertising disabled, as noted in the CIS impact statement.
• .local name resolution on Linux desktops and anything browsing for printers through Avahi.

Rollback commands:

# Linux
sudo systemctl unmask avahi-daemon.socket avahi-daemon.service
sudo systemctl enable --now avahi-daemon.socket avahi-daemon.service

# Windows
Set-NetFirewallRule -Name 'MDNS-In-UDP-Domain-Active' -RemoteAddress Any
Enable-NetFirewallRule -Name 'MDNS-In-UDP-Domain-Active'

# macOS (then reboot)
sudo defaults delete /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements

Common false positive reasons

• A relay answered, not the host. An mDNS reflector or gateway can make a device appear reachable from other VLANs. Fix the relay’s scope.
• Unusual scanner path. Scanning through a VPN or a scanner-only route is accurate for that path; decide whether ordinary users can reach it.
• NAT or port forwarding. UDP 5353 may be forwarded to a different device than the IP in the report.
• Another listener. On Windows, a browser or Teams can still hold UDP 5353 after the OS resolver is off, which is why the firewall method is preferred.
• Stale results. The scan ran before the rule or service change took effect.

FAQ

Is mDNS Detection (Remote Network) a real vulnerability?

It is a genuine exposure, rated Medium by Tenable, but its impact is information disclosure and possible amplification. It does not give an attacker code execution or credentials on its own.

Will blocking UDP 5353 break local printing?

Not if you block it at routed boundaries. mDNS is link-local by design, so devices on the same segment keep discovering each other.

Why does plugin 66717 still appear after the fix?

66717 is the informational local network variant. It fires whenever the scanner shares a segment with an mDNS responder, which is normal if you kept mDNS for local use.

Does the LLMNR Group Policy also disable mDNS?

Do not count on it. The “Turn off multicast name resolution” policy text describes LLMNR only, so handle mDNS with the firewall rules above.

Tracking this finding across many hosts

mDNS findings usually show up on dozens of hosts at once. If you use SITEY, you can upload the .nessus export, have its AI draft host-specific scripts (Avahi or firewall changes) that run only after human approval through SITEY agents on Windows and Linux endpoints, and re-test each Nessus finding to confirm closure. Printers and Macs still need the network-side fix, and duplicates are merged per scanner, not across scanners.

Sources

• Tenable: Nessus plugin 12218, mDNS Detection (Remote Network)
• RFC 6762: Multicast DNS (section 5.5, Direct Unicast Queries to Port 5353)
• CERT/CC VU#550620: mDNS implementations may respond to unicast queries originating outside the local link
• Microsoft Networking Blog: mDNS in the Enterprise
• avahi-daemon.conf(5) man page