Something I’ve recently discovered is zero-configuration networking. It’s surprisingly useful so I thought I’d write up a quick post on it. At a very high level, zeroconf’s aim is to allow you easily browse for available services. If you’re from ‘Apple-land’ you probably know it as Bonjour, their implementation of the standard. To see how it might be useful though, it’s probably worth looking a bit into how it all works. There are 3 key technologies zeroconf uses, Link Local Addressing, Multicast DNS and DNS Service Discovery, so I’ll go through each of them in a high-level overview.

  • Link Local Addressing: This allows a device to allocate itself an IP address in the absence of a manually configured one or a DHCP server. To do this, it first randomly selects an IP address in a specified range. It then sends several ARP requests to this address to check if another device is using it. If it doesn’t get any responses, it starts using this address. It’s a rare situation these days that you don’t have a DHCP server, since pretty much every home router has one built in, so it’s probably the least useful of the 3.

  • Multicast DNS (mDNS): This allows a device to allocate itself a domain name in the absence of a local DNS server. It follows a similar set of steps as Link Local Addressing to allocate a domain name. First, the device chooses a domain name, often based off its hostname. It then sends mDNS queries for this name to check if it’s taken. If it’s unclaimed, the device starts using it. Given most home networks don’t have a local DNS server set up, this is more likely to be useful than Link Local Addressing. It gives you the benefits of a domain name (easier to remember, fairly constant) over that of an IP address. For example, between devices that support zeroconf, you should be able to go to hostname.local and it will look up the appropriate IP address in the background, just like a normal domain name. This is especially handy if you’ve a home server and you don’t want to memorise an IP address.

  • DNS Service Discovery (DNS-SD): This allows devices to advertise what protocols/services they support. It’s built on top of the DNS standard and can work with either regular DNS (unicast) or mDNS. Special SRV records specify the hostname of the machine and the port number used to offer that specific service. E.g. The SRV record _http._tcp.server.local. might tell us server.local is serving HTTP pages at port 80. When a new zeroconf device joins a network, it broadcasts announcement packets saying what services it supports. E.g. A file server might advertise the _ftp._tcp type service. Other devices that can use FTP will remember this and be able to interact with it as needed. DNS-SD employs multiple techniques to reduce protocol traffic on the network, including infrequent polling and goodbye packets as devices leave.

DNS-SD is the layer that really allows you to easily browse for available services, while the 2 other layers are mainly there to ensure networked devices can actually communicate. Each layer doesn’t require the other layers however, as mDNS can use normal DHCP IP addresses as well as Link Local addresses, and DNS-SD supports both unicast and multicast DNS names. Implementing all 3 ensures things should just work however, regardless of how the network is set up.

In theory, this would allow much easier usage of networked resources. Imagine going to a hotel and connecting to their WiFi. You immediately see they offer a “Guest’s Guide” webpage hosted internally. You can browse it like any other website, unaware that it’s using zeroconf networking. One of the pages is a map of the city which you’d like to bring with you. Choosing to print the page brings up a selection of hotel printers automatically, and you can choose whichever is nearest you (e.g. the one labelled “Third Floor Printer”). Maybe later you need to ask the hotel staff a question. Rather than having to look up the phone number, you open up your messaging client and it provides a list of nearby users, including reception. That night you open your video player, and it shows you movies offered by the hotel just as seamlessly as your own local collection. All these features should just work thanks to zeroconf, without the user needing to know what was happening behind the curtain.

So if this is all technically possible, why isn’t it the case already? Unfortunately, support for zeroconf is lacklustre. Apple, having written the original standard, provides good support in both iOS and macOS with Bonjour. Most modern Linux distros also have full support thanks to Avahi. Windows doesn’t have any native implementation, although that could be in the process of changing. Apple also offer Bonjour for windows, although since it isn’t installed by default, most users don’t know about it. Android supports APIs to allow apps interact with zeroconf devices, but these have to be explicitly used by the developers. It means you can’t open a .local domain in your browser and expect it to just work. With the most popular desktop and mobile OSs not supporting the standard, it hasn’t reached the critical mass of users needed to make it ubiquitous. Maybe some hotels in Cupertino have it all set up, but a regular one doesn’t know what zeroconf is and wouldn’t bother to set it up unless most guests wanted it. It feels like we’re within touching distance of the futuristic computers imagined by sci-fi, but until zeroconf receives wider support it will remain an elusive dream.



If you’re interested in learning more about zeroconf, Zero Configuration Networking: The Definitive Guide is a great resource.