Port 5353 – mDNS (Multicast DNS)

Port 5353 is the default port for mDNS (Multicast DNS), the zero-configuration name resolution and service discovery that lets devices find each other on a local network with no DNS server and no manual setup. It’s the backbone of Zeroconf — Apple Bonjour, Linux Avahi, and the mDNS resolvers built into Windows, printers, Chromecast, AirPlay, and a sea of IoT gear. Queries and answers are multicast to 224.0.0.251 (IPv4) or ff02::fb (IPv6) on UDP 5353, so every device on the segment sees them. That openness is the point — and the problem: on a LAN, mDNS is a passive map of every host and service, and its unauthenticated, trust-the-first-answer design puts it in the same name-resolution-poisoning family as LLMNR on port 5355 and NetBIOS-NS on port 137.

Why It’s Open

mDNS is on because Zeroconf “just works,” and vendors ship it enabled. macOS and iOS run Bonjour by default, most Linux desktops run Avahi, Windows 10 and 11 have a native mDNS resolver, and virtually every network printer, smart TV, streaming box, and IoT device announces itself over 5353 out of the box. When a host needs to reach printer.local or discover an AirPlay target, it multicasts the query to 224.0.0.251:5353 and trusts whoever answers. mDNS is meant to stay link-local — RFC 6762 scopes it to the local segment — but misconfigured firewalls, VLAN leakage, or an internet-exposed device can leave 5353 answering where it never should. And where 5353 is open on an internal host, its poisoning cousins LLMNR (5355) and NetBIOS-NS (137) are usually answering on the same box.

Common Risks

• Name-resolution poisoning / spoofing — the headline LAN attack. mDNS has no authentication and accepts the first answer it gets, so an attacker on the segment can reply to a victim’s .local lookup with their own address, redirecting the victim to a malicious SMB or HTTP service and capturing an NTLMv2 hash. Responder poisons mDNS, LLMNR (5355), and NBT-NS (137) at the same time — which is why disabling only one leaves the door open. Cracked offline or relayed to another host, that hash becomes a foothold.
• Passive reconnaissance / information disclosure. Bonjour and Avahi advertise hostnames, OS and device model, and every running service — _ssh._tcp, _http._tcp, _smb._tcp, AirPlay, printers. An attacker just listens and enumerates the whole subnet — hosts, roles, and software — without sending a single packet that looks like an attack.
• Reflection / amplification DDoS. An mDNS responder reachable from outside the local link answers unicast queries it should ignore, so a spoofed-source query makes it fire a much larger reply at a victim. It’s the same UDP-reflector abuse as SSDP (1900) and NTP (123); CERT/CC catalogued it as VU#550620 and CVE-2017-6520 is exactly this failure in a shipping product.
• Implementation bugs in the mDNS stack. The daemons themselves — Apple mDNSResponder and Linux Avahi — have carried remote code execution and denial-of-service flaws (see CVEs below), so an exposed responder is more than an information leak.
• Unintended exposure. mDNS should never cross a VLAN boundary or reach the internet. Reflector-hunting scanners find open 5353 constantly; if yours answers from outside the LAN, that is a misconfiguration to close, not to harden.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check if it’s open

nmap -sU -p 5353 -sV <target>

Enumerate advertised services (DNS-SD)

nmap -sU -p 5353 --script dns-service-discovery <target>

Discover mDNS/DNS-SD devices on the local segment (multicast)

nmap --script broadcast-dns-service-discovery

Browse services with the native Zeroconf tools

avahi-browse -alr                          # Linux (Avahi)
dns-sd -B _services._dns-sd._udp local.    # macOS (Bonjour)

Send a raw DNS-SD query

dig @224.0.0.251 -p 5353 _services._dns-sd._udp.local PTR +short

Test name-resolution poisoning (authorized engagements only)

sudo responder -I eth0

Every hostname, service record, and OS fingerprint mDNS hands you — and every hash Responder captures — is both a finding and a map of the subnet, so keep it in the pentest report rather than terminal scrollback you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2017-6520 — The mDNS responder in the BOSE SoundTouch 30 answers IPv4 unicast queries whose source is not link-local, letting a remote attacker cause a denial of service (traffic amplification) or obtain sensitive information via UDP 5353. CVSS 3.0 9.1 (Critical). It’s the reflection/amplification failure — the same behaviour CERT/CC describes generically in VU#550620 — in a shipping mDNS device.
• CVE-2007-2386 — Buffer overflow in Apple mDNSResponder (the Bonjour daemon) on Mac OS X 10.4–10.4.9: a crafted UPnP Internet Gateway Device (IGD) packet causes a denial of service or remote code execution as root. CVSS v2 9.4; weaponised in Metasploit and archived on Exploit-DB. Proof the mDNS/Bonjour daemon itself has carried pre-auth RCE, not just leaks.
• CVE-2021-3468 — Avahi 0.6 through 0.8 mishandles the client-connection termination event in client_work, letting a local attacker trigger an infinite loop that hangs the daemon (denial of service). CVSS 3.1 5.5.
• CVE-2023-38469 through CVE-2023-38473 — A cluster of reachable-assertion and use-after-free denial-of-service flaws in Avahi (in avahi_dns_packet_append_record, avahi_escape_label, the D-Bus SetHostName handler, avahi_rdata_parse, and avahi_alternative_host_name), fixed in Avahi 0.9. CVSS 3.1 5.5 each — patch-relevant on RHEL/Fedora and other Linux hosts running the daemon.

mDNS reflection/amplification itself isn’t a single CVE — it’s a design/misconfiguration issue in how open responders answer spoofed unicast queries, the same UDP-reflector class US-CERT catalogued in TA14-017A for DNS, NTP, and SSDP.

Mitigation

• Block UDP 5353 at network boundaries; never expose mDNS to the internet. Keep it link-local — it should never cross a VLAN or reach the WAN. An internet-facing port 5353 has no legitimate purpose and doubles as a reflector.
• Disable Bonjour/Avahi where it isn’t needed. On servers and enterprise desktops that don’t use Zeroconf, stop the mDNS service — avahi-daemon on Linux, the Bonjour Service on Windows.
• Disable mDNS, LLMNR, and NBT-NS together. Responder poisons all three, so kill them as a set: the “Turn off multicast name resolution” GPO covers LLMNR (5355) and mDNS, and NetBIOS over TCP/IP handles 137. Rely on properly maintained internal DNS (53) instead.
• Segment IoT and print VLANs. Keep chatty Bonjour/Avahi devices off user and server subnets so their broadcasts can’t map the whole network.
• Enforce SMB signing and channel binding. A poisoned hash is only dangerous if it can be relayed — signing and LDAP channel binding blunt that path, the same defense that matters on the LLMNR and NBT-NS pages.
• Monitor for spoofed mDNS. A host answering .local names it doesn’t own is the classic poisoning tell; alert on it in network/endpoint monitoring.
• Patch avahi and mDNSResponder. Update to close the DoS/RCE bugs above; on abandoned IoT where no fix exists, disable mDNS entirely.

Real-World Example

The reliable internal-pentest opener is to start Responder and wait. A Windows or macOS host tries to reach a name that DNS can’t resolve — a mistyped share, a decommissioned something.local — and falls back to multicasting the query over mDNS (and LLMNR, and NBT-NS) on the local segment. Responder answers “that’s me” on all three, the victim connects and authenticates, and the tester walks off with an NTLMv2 hash to crack offline or relay straight to another host. No exploit, no malware — just mDNS trusting the first machine to answer, exactly like LLMNR (5355) and NBT-NS (137). Separately, misconfigured internet-facing mDNS devices — the CVE-2017-6520 / VU#550620 class — get swept up as reflection/amplification sources, the same way exposed SSDP (1900) and NTP (123) responders do.

FAQ

What is port 5353 used for?

Port 5353/UDP carries mDNS (Multicast DNS), the Zeroconf protocol that resolves .local hostnames and discovers services on a local network without a DNS server. Devices multicast queries and announcements to 224.0.0.251 (or ff02::fb on IPv6), and it’s the transport behind Apple Bonjour, Linux Avahi, AirPlay, AirPrint, Chromecast, and most IoT discovery.

Is port 5353 dangerous?

On a trusted LAN it’s routine, but it’s a dependable attacker asset. Because mDNS is unauthenticated and trusts the first answer, an attacker on the segment can poison name lookups to capture NTLM hashes (via Responder), and passive listening reveals every host, OS, and service. Exposed to the internet it becomes a reflection/amplification DDoS source and can expose implementation bugs in Avahi or mDNSResponder. Treat any mDNS answering from outside the local link as an exposure to close.

What’s the difference between mDNS, LLMNR, and NetBIOS-NS?

They’re three broadcast/multicast name-resolution protocols that kick in when normal DNS (53) doesn’t answer. mDNS (5353) is the cross-platform Zeroconf/Bonjour resolver for .local names and service discovery; LLMNR (5355) is Microsoft’s link-local equivalent; and NetBIOS-NS (137) is the legacy Windows name service. All three are unauthenticated, all three are poisoned by Responder, and all three should be disabled together on managed networks.

How do I disable mDNS or close port 5353?

Stop the mDNS service where it isn’t needed (avahi-daemon on Linux, the Bonjour Service on Windows), and disable LLMNR and NetBIOS at the same time so poisoning has no fallback. Firewall UDP 5353 at VLAN boundaries and the perimeter so it never leaves the local link, segment IoT and printers onto their own VLANs, and patch Avahi/mDNSResponder. Rescan with nmap -sU -p 5353 <target> to confirm it no longer answers.

TL;DR

• Service: mDNS (Multicast DNS) — Zeroconf name resolution and service discovery (Apple Bonjour, Linux Avahi)
• Default port: 5353/UDP (multicast 224.0.0.251 / ff02::fb)
• Biggest risk: LAN name-resolution poisoning (Responder → NTLM hash capture/relay) and passive recon; reflection/amplification DDoS if exposed to the internet
• Mitigation: block 5353 at boundaries, disable mDNS/LLMNR/NBT-NS together, segment IoT VLANs, enforce SMB signing, and patch avahi/mDNSResponder