What We Cover
Comprehensive resources on mDNS, DNS-SD, and the tools that make zero-configuration networking possible.
Multicast DNS (mDNS)
Deep-dive into the mDNS protocol operating on :5353. Understand how devices resolve hostnames without a central DNS server.
DNS Service Discovery
Learn how DNS-SD leverages port 5353 to advertise and discover services automatically across local networks using standard DNS records.
Network Engineering Tools
Explore command-line utilities, packet analyzers, and open-source tools for inspecting and debugging mDNS traffic on your network.
Security & Best Practices
Understand the security implications of mDNS exposure, how to isolate traffic, and recommended configurations for production environments.
Explore Cloud VPS
Trusted Tech Networking Tools resources handpicked by our editorial team.
Understanding Port 5353 & mDNS
What Is Port 5353?
Port 5353 is the designated UDP port for Multicast DNS (mDNS), a protocol defined in RFC 6762. Unlike traditional DNS, which relies on a centralized server infrastructure, mDNS operates entirely on the local network segment. When a device needs to resolve a hostname ending in .local, it sends a multicast query to the address 224.0.0.251 (IPv4) or FF02::FB (IPv6) on port 5353. Any device on the same subnet that recognizes the queried name responds directly, eliminating the need for manual DNS configuration.
DNS-SD: Service Discovery Over mDNS
DNS Service Discovery (DNS-SD), standardized in RFC 6763, works hand-in-hand with mDNS on port 5353. It uses standard DNS record types — PTR, SRV, and TXT — to advertise and browse network services. A printer, for example, announces its presence by registering a PTR record under _ipp._tcp.local. Clients browsing for printers multicast a query on :5353 and receive responses from all available printers on the segment. This mechanism powers automatic discovery of printers, smart TVs, IoT devices, Chromecast, AirPlay, and countless other services without any user configuration.
How mDNS Packets Work
An mDNS query packet is structurally identical to a standard DNS packet, but sent via UDP multicast rather than unicast to a known server. Queries carry a QU (Question Unicast) bit indicating whether the sender prefers a unicast or multicast response. Devices that have recently answered the same query suppress their response to reduce network chatter — a mechanism called "Known Answer Suppression." Responses are cached locally with TTL values, and devices send "Goodbye" packets (TTL=0) when they leave the network, allowing peers to invalidate stale cache entries promptly.
Common Use Cases in Modern Networks
Port 5353 traffic is ubiquitous in enterprise Wi-Fi, home networks, and development environments. Developers use tools like dns-sd, avahi-browse, and nmap with mDNS probing to inventory local services during troubleshooting. In containerized environments, mDNS facilitates service discovery between containers on the same Docker bridge network. Network engineers must be aware that mDNS is link-local by design — it does not cross router boundaries — making it safe for local discovery while requiring explicit mDNS proxy configurations for multi-subnet environments.
Why mDNS & Port 5353 Matter
Key advantages that make multicast DNS an indispensable protocol for modern networking.
Zero Configuration
Devices discover each other automatically — no DNS server setup, no manual IP mapping required.
Cross-Platform Support
Native support on macOS, Windows, Linux, iOS, and Android via Bonjour, Avahi, and built-in resolvers.
Low Network Overhead
Multicast queries only reach interested devices. Known-answer suppression minimizes redundant traffic.
Link-Local Isolation
By design, mDNS traffic stays within the local subnet — reducing exposure to external network threats.
Standard DNS Records
DNS-SD reuses familiar PTR, SRV, and TXT record types — no proprietary formats to learn.
IoT & Smart Home Ready
Powers device discovery for Chromecast, HomeKit, Matter, and virtually all smart home ecosystems.
Frequently Asked Questions
Answers to the most common questions about port 5353, mDNS, and network discovery.
What exactly is port 5353 used for?
Port 5353 is the official UDP port assigned by IANA for Multicast DNS (mDNS). It is used by devices on a local network to resolve hostnames ending in .local and to discover services without requiring a centralized DNS server. Traffic on this port is always sent to the multicast group address 224.0.0.251 for IPv4 or FF02::FB for IPv6.
Is mDNS the same as regular DNS?
mDNS uses the same packet format as standard DNS (RFC 1035) but operates fundamentally differently. Standard DNS sends unicast queries to a known server IP. mDNS sends multicast queries to a link-local group address, and any device on the local segment can respond. mDNS is strictly link-local — it cannot traverse routers without an mDNS proxy or repeater.
How do I inspect mDNS traffic on my network?
Several tools make mDNS inspection straightforward. On macOS and Linux, dns-sd -B _services._dns-sd._udp local browses all advertised services. On Linux with Avahi, avahi-browse --all --resolve lists every discovered service. Wireshark can capture mDNS packets by filtering on udp.port == 5353. The nmap scanner also supports mDNS probing with appropriate scripts.
Should I block port 5353 in my firewall?
For most home and development networks, port 5353 should be allowed within the local subnet to enable device discovery. In enterprise or high-security environments, you may want to restrict mDNS to specific VLANs and block it at inter-VLAN boundaries. Because mDNS is link-local, it cannot traverse your perimeter firewall by default — the risk is primarily information disclosure (device names and services) within the local network.
What is the difference between mDNS and DNS-SD?
mDNS (RFC 6762) is the transport mechanism — it defines how DNS queries and responses are sent via multicast on port 5353 without a central server. DNS-SD (RFC 6763) is the service layer built on top of mDNS — it defines the naming conventions and record types (PTR, SRV, TXT) used to advertise and browse services. They are complementary: DNS-SD specifies what to advertise, mDNS specifies how to advertise it on the local network.
Start Exploring Network Discovery
Dive deeper into mDNS protocols, tooling guides, and network engineering best practices curated by 5353.io.
Read the Full Guide