The problem discovery solves
On the internet, finding a machine means asking DNS to turn a name into an address. That works because DNS servers exist and everyone knows where they are.
Your local network has no such server. Devices come and go constantly, and their addresses are handed out on the fly. Something has to let a phone work out that there's a laptop nearby and what address it has right now, without either one being told about the other in advance.
How mDNS works
Multicast DNS solves this by getting rid of the server. Instead of asking one machine, a device sends its question to a multicast address that every device on the subnet is listening to, and whichever one owns the name answers.
It's the mechanism behind names ending in .local, and it uses UDP port 5353.
- Bonjour
- Apple's version, built into macOS and iOS, and how AirPlay and network printers get found.
- Avahi
- The equivalent on most Linux distributions.
- Native mDNS
- Built into Windows since Windows 10, which is why .local names resolve there without extra software.
Multicast stops at the subnet
This is the consequence worth remembering. Multicast messages go to devices on the local subnet, and routers don't forward them past it by default.
So discovery works beautifully within one network and not at all across two. It explains why a guest network can't see the main one, why devices on separate VLANs never find each other, and why discovery has nothing to do with your internet connection. The traffic never leaves the building.
Not every app uses mDNS
mDNS is the most common approach, not the only one. Some apps broadcast on the subnet on a port of their own, and some just let you type an address in.
FileFly finds devices and sends files on port 23013. The subnet rule still applies: both devices have to be on the same local network, and a firewall blocking that port will stop them finding each other even when everything else is right.