A ZoomEye query for port="5353" returned 4,669,414 matches on 28 October 2026. Port 5353 is multicast DNS. It exists so that a device can be found without a DNS server, a DHCP lease record or an asset database entry: the device announces itself on 224.0.0.251 and anything on the same segment can listen.

That design decision is reasonable for a home network with a printer. On a corporate network it produces a continuously updated, unauthenticated inventory of every device that speaks it, readable by any host on the segment.

What the query selects, and what it cannot

port="5353" matches hosts that responded on UDP 5353. mDNS is stateless from the probe point of view: a single query for _services._dns-sd._udp.local is normally enough to elicit a reply from every responder on that address, because the responder answers to the multicast address it is already listening on. The probe cannot enumerate a whole segment from outside it; the count therefore reflects individual reachable hosts, not networks. A number in the millions means millions of individual responders, not millions of LANs.

One limit applies to every reading of this figure: mDNS is intended to be link-local. A host appearing in the corpus is one whose 5353 traffic reached a probe host, which usually means the segment was routed, bridged or exposed by a VPN concentrator or a virtualisation platform. The number measures a configuration choice, not a default.

What the replies contain

DNS-Based Service Discovery (RFC 6763) defines the record types that make mDNS useful, and the same records make it informative to a stranger.

  • Service enumeration. A query for _services._dns-sd._udp.local returns the list of service types the host advertises: _ipp._tcp, _airplay._tcp, _raop._tcp, _smb._tcp, _ssh._tcp, _workstation._tcp, _googlecast._tcp, _printer._tcp. The list is a description of the device's role.

  • Instance names. Each service returns a human-readable instance name, and in practice those names carry asset tags, room numbers, owner names and, on a surprising number of devices, the default admin password the installer set.

  • Hostname and addresses. The A and AAAA records give the device's .local name and its current addresses, which is how an attacker on the segment turns a broadcast into a target list.

  • TXT records. These carry key-value pairs for the service. For printers they include model and queue names; for some appliances they include version strings and configuration paths.

None of this requires authentication, and none of it is unusual. It is the protocol working as specified.

Where it becomes a security problem

Three conditions turn mDNS from convenience into exposure.

  1. 1.

    Extending the segment. A VPN concentrator that bridges clients onto the office VLAN carries mDNS with them. So does a hypervisor with a flat virtual switch. The protocol was designed for one physical link, and a routed link inherits the entire discovery surface of the LAN behind it.

  2. 2.

    Name-based trust. Services on some platforms are trusted by hostname. A responder can claim a .local name that another device is expected to use, and clients that resolve before connecting will follow the claim. RFC 6762 addresses conflict resolution, but conflict resolution is not authentication.

  3. 3.

    Inventory drift. An asset register built from a scanner that lists 5353 as an excluded protocol will miss the devices that only announce themselves this way: conference room units, print servers, media boxes, lab instruments and embedded controllers that have no other management interface.

A short work list

  1. 1.

    Run the enumeration from a host on each segment: dns-sd -B _services._dns-sd._udp on macOS, avahi-browse -a on Linux. Compare the result with the asset register. The difference is the finding.

  2. 2.

    Block 5353 at routed boundaries. mDNS has no legitimate reason to cross a router unless a specific discovery proxy is deployed, and a discovery proxy is a deliberate design decision rather than a default.

  3. 3.

    Fix VPN client bridging. Clients that receive a virtual adapter bridged onto the office LAN bring their own mDNS responders with them, including the host's own services.

  4. 4.

    Review what the TXT records and instance names disclose. A printer named after a project or a device named after its owner is a small disclosure that accumulates.

  5. 5.

    For the subset of devices that need discovery across subnets, use a documented proxy and log its responses, so discovery becomes an auditable service rather than a broadcast.

Reading the number correctly

4,669,414 is not a count of vulnerable systems. It is a count of hosts that answered on a port whose entire purpose is to be answered to. The useful conclusion is narrower and more actionable: mDNS does not stay on the link it was designed for, and once it leaves, it is a discovery protocol serving parties other than the intended client.

Sources

  • ZoomEye AI SDK query port="5353", page size 1, sub_type all, executed 28 October 2026 Beijing time: 4,669,414 matches.

  • RFC 6762, Multicast DNS, including multicast addressing and conflict resolution.

  • RFC 6763, DNS-Based Service Discovery, defining service enumeration and TXT record semantics.