A network is just a sophisticated way of connecting clients to servers and services. To make this work, clients and servers need addresses, and some services need to be discovered. This is the responsibility of some largely unseen but vitally important background services in OS X.

Prior to 10.10 Yosemite, clients have relied on Bonjour’s multicast Domain Name Service Responder, mDNSResponder, running as a daemon, therefore listed in the processes inspected in Activity Monitor. As has recently been pointed out by Iljitsch van Beijnum on Ars Technica, this has suddenly changed in Yosemite.

Each networked Mac, and other devices such as routers and printers, has two different identifiers: the Ethernet port which is connected to the network has a MAC (Medium Access Control) address set in its firmware, something like 01:23:45:67:89:ab, to uniquely identify that interface. However devices on a network are also assigned more temporary and snappier Internet Protocol (IP) addresses such as 192.168.1.20, with which we are more familiar.

IP addresses are great for computers, but not the sort of thing that humans can carry around in their head. So we normally use a third identifier, an Internet name constructed on a recognised domain name, such as eclecticlight.co, or http://www.apple.com.

The task of converting between the Internet name and IP address is performed by a Domain Name Server (DNS), usually specified in a couple of IP addresses supplied by your ISP. Networking hardware, such as a local Ethernet switch, then converts between IP and MAC addresses, an essential lower-level service using the Address Resolution Protocol (ARP).

If your Mac(s) and other networked devices all have fixed IP addresses, then all that OS X has to do is resolve names and addresses, something that until Yosemite has fallen to mDNSResponder to handle.

Most local networks also allow devices, particularly mobile systems such as laptops, smartphones, and tablets, to acquire temporary IP addresses from a pool, managed by a Dynamic Host Configuration Protocol (DHCP) server, typically in the router. However DHCP can create all sorts of problems, and with so many devices now incorporating DHCP servers, it is easy to end up with two DHCP servers on the same local network, which quickly causes chaos.

Apple’s Bonjour (originally known as Rendezvous) offers a much smarter and neater solution in what is known as ‘zero configuration’ coupled with ‘link-local address allocation’. Cutting a long story short, when you connect a Mac with Bonjour enabled and no fixed IP address to a network without a DHCP server, OS X picks an IP address semi-randomly within a reserved block upwards from 169.254.1.0. Having chosen that, it broadcasts a request for any device with that same IP address to respond, to ensure that it is not committing the cardinal sin of using someone else’s IP address. If there is no response, it will assume that address, so broadcasts that it is its owner. These exchanges use ARP network packets, so are readily recognised when you watch a network using a packet sniffer such as Wireshark.

Another important task in Bonjour is to handle the discovery of network services rather than merely the address of a server or client. These days services are quite common, including printing, music, photo sharing, and movies/TV. This is carried out using a scheme termed DNS Service Discovery, DNS-SD.

Bonjour has its own naming system for devices, recognisable by the suffix .local, which unfortunately can clash with naming schemes under Windows. So your Mac, with Bonjour available, will have a fourth name, such as HowardsMac.local. Bonjour can also extend over the Internet, where it is known as ‘wide-area Bonjour’, although that remains a somewhat unusual pursuit.

So how has this changed in Yosemite? The most obvious thing is that the fairly robust and proven mDNSResponder has gone, replaced by a stripling and clearly less than perfect service daemon named discoveryd. As Iljitsch van Beijnum points out, there are several issues that do not instil confidence, not least of which is that documentation is minimal. Browse the gigabytes of documentation about Yosemite, and you will be hard put to even find mention of this major change. You could argue that, for all but a handful of techies, no docs are needed, as like mDNSResponder it should ‘just work’. But the reports of problems on Ars Technica, Apple’s support discussions, and elsewhere make it clear that it does not ‘just work’, yet.

So in Yosemite, when you browse active processes, mDNSResponder has gone, and discoveryd runs in its place. It is responsible for:

• regular (‘unicast’) DNS resolution to convert between Internet names and IP addresses
• multicast DNS resolution (mDNS) as part of the Bonjour package
• Service Discovery (DNS-SD), to support access to network services including those of local and wide-area Bonjour.

You cannot fiddle with the discoveryd daemon itself, or its helper discovery_helper, but must work through the shell utility, discoveryutil. To get the full details of its many and complex commands and options, type man discoveryutil in Terminal.

Useful starting points for exploring this new system are the commands (all of which must be run as root, by prefacing the command with sudo):
discoveryutil clientlisteners : lists active client listeners for different services
discoveryutil configresolvers : lists current network resolvers
discoveryutil mdnsbrowses : lists current mDNS browses
discoveryutil mdnslisteners : lists current mDNS listeners
discoveryutil udnsresolvers : lists current unicast DNS resolvers, many of which will relate to iCloud and similar services.

Other related shell commands include dns-sd, a test tool for mDNS and DNS-SD, intended primarily for access by an app through its library, and dig, the standard DNS lookup utility.

Mario Ciabarra has also identified problems with running Bonjour over Apple Wireless Direct Link (AWDL), a feature new to Yosemite which could also relate to bugs in discoveryd, perhaps.

The tools available for exploring and diagnosing resolution and discovery problems have otherwise apparently remained unchanged. Network Utility is now hidden away in /System/Library/CoreServices/Applications, which is a pretty daft place to hide such an essential tool. In that same folder you will find Wireless Diagnostics, which is also very useful at times. Wireshark and other packet sniffers require a lot of patience, deep understanding, and are far from simple.

As the next few years will see many, if not most, of us switching from traditional IPv4 addresses like 192.168.1.25 to IPv6 addresses like fe80:0000:0000:0000:0217:f2ff:fe4d:2f70, another layer of bugs and uncertainty is not exactly welcome. Hopefully Apple will soon come clean and explain why they have ditched mDNSResponder, and how discoveryd is so much better.