How do devices discover services without a server or DNS?

Before one device can use a service on another, it needs three answers: which devices offer the service, how to reach each one, and enough detail to choose between them. On the internet, a central directory answers them. DNS turns names into addresses, and service registries list which servers run which service.

That works until the directory is out of reach. With no internet, no DNS server and no registry, devices need another way to find each other. Service discovery without a server replaces the directory with two simple acts: devices announce what they offer, and devices ask who offers what they need.

When devices share a local network, such as the same Wi-Fi access point, the standard answer comes from two IETF specifications.

Multicast DNS (RFC 6762) lets devices perform DNS-like lookups on the local link with no DNS server. Instead of asking a server, a device sends its query to a multicast address, 224.0.0.251 for IPv4 or FF02::FB for IPv6, on UDP port 5353, and whichever device holds the answer replies. Names ending in .local. are reserved for this, so a laptop can answer to a name such as MyComputer.local. with no configuration.

DNS-Based Service Discovery (RFC 6763) adds a way to browse for services rather than look up a known name. A client asks for a service type in a domain, such as _ipp._tcp for printers, and gets back a list of named instances. Each instance has an SRV record giving the host and port to connect to, and a TXT record carrying extra details as key and value pairs. DNS-SD works over ordinary unicast DNS too, but paired with multicast DNS it needs no configuration at all.

Both major phone platforms build on this pairing:

• Apple’s Bonjour is zero-configuration networking for discovering, publishing and resolving services on a local network using standard IP protocols. Apple publishes its implementation as open source under the Apache 2.0 license.
• Android’s network service discovery (NSD) implements DNS-SD, so an app can register a service type such as _nsdchat._tcp and find instances of it on the local network. Android’s documentation notes that DNS-SD is supported on other mobile platforms as well, which is why phones from different makers can find each other this way.

Multicast DNS is link-local by design. Its queries go to a link-local multicast address and are answered by devices on the same link. That makes it simple, and it also bounds it. Devices have to be on the same network segment for discovery to work.

Take the access point away and there is no shared link to multicast on. Two phones in a field, a basement or a disaster zone may be within a few metres of each other and still have no network in common. For those cases, discovery has to happen at the radio level.

Phones carry radios that can find each other directly, with no access point.

Bluetooth Low Energy advertising. A device in the peripheral role broadcasts small advertising packets, which can include the UUIDs of the services it offers, and devices in the central role scan for them. Apple’s Core Bluetooth lets an app scan only for peripherals advertising particular service UUIDs, and recommends doing so; to scan in the background on iOS, an app must name the services it is looking for. On Android, an app can pass scan filters that restrict which devices a scan reports.

Wi-Fi Aware. Also called Neighbor Awareness Networking (NAN), Wi-Fi Aware lets devices running Android 8.0 (API level 26) and later discover and connect to each other with no other connectivity between them. One device publishes a service, another subscribes to it, and when the subscriber comes within Wi-Fi range it is told a matching publisher is nearby. It can then send a short message or set up a direct network connection.

Both methods find only neighbours within radio range. That is enough for two devices, but not for a service that sits several devices away.

In a mesh, devices already relay messages for each other, so they can relay discovery too. A query for a service type is passed from device to device, using the same hop limits and duplicate suppression as any other message to stop it circling (How does a message cross a mesh network? explains these). Devices that offer the service answer, and the answer travels back across the mesh. A requester can then send a request to the provider it picks, even though the two have no direct link.

Two design questions matter more here than on a home network.

Who is allowed to answer? Anyone in range can announce a service. RFC 6762’s own security section notes that multicast DNS assumes cooperating participants, and says that where untrusted hosts may share the link, participants need signatures to tell trusted messages from the rest. A mesh app should verify who an advertisement comes from and decide in its own code which providers it trusts.

Who can read it? Discovery traffic is often readable by the devices that carry it. In the Offline Protocol mesh SDK, for example, MeshServices lets a device register a capability that others discover and invoke with request and response across the mesh. In v0.27.0, service advertisements, requests and responses are signed plaintext control messages: they are attributable and tamper-evident, but readable by anyone observing the transport. Confidential content belongs in messages encrypted with MLS.