mDNS Auto-Discovery: How Devices Find Each Other on Your Network

What mDNS Actually Does (in Plain English)

Multicast DNS (mDNS) lets devices on the same local network find each other with no DNS server and no setup. It is defined in RFC 6762. Apple's implementation is called Bonjour. It is how AirPlay speakers, Chromecasts and network printers show up in a list without you typing an address.

Normal DNS asks a server. mDNS sends the question to a multicast address that every device on the network listens to, and the device that owns the answer replies. It is usually paired with DNS-SD (DNS Service Discovery, RFC 6763), which lets a device ask "who offers this kind of service?" instead of "what is the address for this name?".

OpenDrop uses both. The desktop app on Windows or Linux advertises a service of type _opendrop._tcp.local. on port 8000. After your phone pairs with the computer by scanning its QR code, the phone browses for that service type and finds the computer on the same Wi-Fi without you typing its address. With OpenDrop Pro, phones and computers signed in to the same account find each other the same way without a QR code.

When discovery fails, the cause is usually one of the four problems below.

Problem 1: Nobody Wants to Type IP Addresses

The problem: Without discovery, one device has to know the other's IP address, such as 192.168.1.42. Home routers hand out addresses with DHCP, and a device can get a different one after a reboot or when its lease runs out.

How mDNS solves it: Devices look each other up by service type and name instead of by address. Your phone does not need to know that your PC is at 192.168.1.42. It asks for _opendrop._tcp.local., and the answer includes the current address and port.

The questions and answers are UDP packets sent to the multicast group 224.0.0.251 on port 5353 (FF02::FB on IPv6). Every mDNS-aware device on the network joins that group. On a healthy network, a query gets its answer in well under a second.

What to do when it fails: If the computer still hasn't shown up after 15 seconds or so, the packets are not getting through. Start by checking that both devices are on the same subnet. Run ipconfig on Windows or ip addr on Linux, and look at the Wi-Fi details on your phone. On a typical home network (a /24), the first three numbers must match: 192.168.1.20 and 192.168.1.42 can see each other, 192.168.1.20 and 192.168.0.42 cannot. The usual culprits are a guest network, a second router running its own network, or a VPN, which can also block local traffic outright. Turn the VPN off and try again.

Problem 2: Manual Network Configuration Is Error-Prone

The problem: The traditional ways to share files between computers, SMB (Windows file sharing, or Samba on Linux) and NFS, need setup: shared folder paths, user accounts and passwords, and firewall rules. Every step is one more thing that can be wrong, and the error messages rarely tell you which one.

How mDNS solves it: mDNS belongs to a family of protocols called zero-configuration networking, or zeroconf. The family has three parts: link-local addressing, which gives a device a 169.254.x.x address when there is no DHCP server; mDNS, which resolves names; and DNS-SD, which lists services. There are no config files and no server to set up. An app registers its service, and other apps browse for it.

In code it is short. OpenDrop's desktop app uses the Python zeroconf library: it builds a ServiceInfo with the service type, LAN address, port and a few text properties, and registers it. Browsing is a ServiceBrowser with a listener that the library calls when a matching service appears or goes away.

What to do when it fails: If other devices work (AirPlay, a Chromecast, a printer) but one app's devices never appear, the network may be filtering by service type. Business Wi-Fi systems often run an mDNS gateway or Bonjour policy that only passes approved service types, so check your router or controller for mDNS or Bonjour settings. You can also look at what is being advertised. On a Mac, dns-sd -B _services._dns-sd._udp lists every service type on the network. On Linux, avahi-browse -a does the same, and avahi-browse -r _opendrop._tcp shows OpenDrop computers with their addresses. Run these from a different machine than the one running OpenDrop. If the OpenDrop computer is missing from the list, the problem is on that computer or its firewall, not on the phone.

Problem 3: Firewalls and Routers That Block Discovery

The problem: mDNS depends on UDP multicast on port 5353, and many networks block or limit it. Hotel, campus and corporate Wi-Fi often do. Routers with "AP isolation" or "client isolation" turned on, which is the default on many guest networks, stop devices from talking to each other at all. Some routers also pass multicast badly between their 2.4 GHz and 5 GHz bands, or between mesh nodes.

Firewalls on the computer cause the same symptom. Windows treats a network marked Public as untrusted and blocks most incoming local traffic.

mDNS has no way around this. If the multicast packets don't arrive, no app can discover anything with it.

What to do when it fails: Work through these in order:

1. Check the firewalls. On Windows, open Settings, then Network and internet, and set your Wi-Fi network to Private. Then make sure OpenDrop is allowed through Windows Defender Firewall on private networks. On Linux with ufw, allow mDNS and OpenDrop's port: sudo ufw allow 5353/udp and sudo ufw allow 8000/tcp. On the router, look for settings named mDNS, Bonjour, multicast, AP isolation or client isolation. Turn isolation off, and keep your phone off the guest network.
2. Check Local Network access on iPhone and iPad. iOS asks before an app can use your local network. If that permission is off, the app can't find anything on your Wi-Fi. Turn it on in Settings, Privacy and Security, Local Network.
3. Use the QR code. OpenDrop's QR code holds a private pairing key and the addresses your phone needs to reach your computer, so the phone can connect without mDNS as long as the network lets the two devices talk directly. Anyone who scans it can pair with your PC, so don't share screenshots of it. There is more on this in how QR code pairing works.
4. Send over the internet instead. If the local network blocks device-to-device traffic entirely, OpenDrop picks another route: a direct peer-to-peer link or OpenDrop's own encrypted relay. Both devices connect outward, so it works behind NAT and most firewalls, with no port forwarding and nothing extra to install. Neither plan has a file size cap. Free remote transfers are speed-limited and share a weekly allowance; Pro uses a faster relay with no weekly limit.

Problem 4: Devices on Different Networks Can't Discover Each Other

The problem: mDNS only works on the local link. The address 224.0.0.251 is in the 224.0.0.0/24 block, which routers never forward to another network. So if your phone is on cellular data, or your laptop is at a café while your PC is at home, mDNS will not find anything. That is intentional: service announcements from your home network should not leak onto the internet.

How OpenDrop handles it: OpenDrop keeps discovery and transfer separate. mDNS is only used to find the computer on the local network. Away from home, the phone uses what it got from the QR code (or, with Pro, from your account) to reach the computer over a direct peer-to-peer link or OpenDrop's relay. You don't need port forwarding or dynamic DNS. When both devices are on the same Wi-Fi, OpenDrop uses the local route first, at full speed, on both plans.

Away from your Wi-Fi, the route depends on the plan. Free tries peer-to-peer first, then the shared relay. Free remote transfers are speed-limited, move in resumable 5 MB pieces and share a weekly allowance. Pro starts on the faster Pro relay, keeps peer-to-peer as a backup, and streams whole files with no weekly limit. File contents are encrypted on your device before they leave it; the relay can still see file names, sizes and device names, which it needs to route the transfer. The encryption guide has the details.

What to do when it fails: Both devices need a working internet connection that allows outbound HTTPS and secure WebSocket traffic. If the phone can't reach the computer from outside, check that the computer is awake, OpenDrop is running on it, and nothing on its network blocks outbound connections. A VPN on either device can also get in the way.

How mDNS Works in Practice: A Packet-Level Walkthrough

Here is what goes over the network when a Windows PC running OpenDrop and an iPhone that has already scanned its QR code are on the same Wi-Fi.

1. The computer probes, then announces. When the desktop app starts, it joins the 224.0.0.251:5353 group. It first sends a few probe queries, a fraction of a second apart, to check that no other device already uses its service instance name. If one does, OpenDrop registers under a different unique name. Then it announces its records to the whole group: a PTR record saying "here is an instance of _opendrop._tcp.local.", an SRV record with its host name and port 8000, a TXT record with properties such as the device name and app version, and an A record with its IP address, for example 192.168.1.100.

2. The phone asks. When the OpenDrop app opens, it sends a PTR query for _opendrop._tcp.local. to the same group. Every computer running OpenDrop on the network answers. The phone matches each answer against the computer it paired with and ignores the rest. Then it connects to that address and port, checks the computer's certificate against the fingerprint from the QR code, and signs its requests with the secret the two devices share.

3. Caching and refresh. Every record carries a TTL. RFC 6762 recommends 120 seconds for records that contain a host name (A, AAAA and SRV) and 75 minutes for the rest (PTR and TXT). A device that still cares about a record asks again when 80% of its TTL has passed, and again at 85, 90 and 95% if nobody answers. If there is still no answer, the record is dropped.

4. Goodbye. When a service shuts down cleanly, it sends its records one more time with a TTL of 0. Other devices remove them about one second later.

A crash, a power cut or a dropped Wi-Fi connection sends no goodbye. Other devices keep the stale entry until its TTL runs out, which is why a device can stay in a list for a while after it is gone.