Chapter 3. Names Without DNS

In Chapter 2, you saw how Zeroconf allows your device to obtain a locally unique IP address without a DHCP server or a network administrator. The next step is to obtain a name that can resolve to this address. The method you use to do that is independent of how you have obtained your IP address; for example, you may have taken advantage of link-local addressing, been assigned an address using DHCP, or manually assigned an IP address. If you need a name that is at least locally unique and there is no DNS server available, the Multicast DNS (mDNS) mechanism will help you obtain one.

This stage may feel unnecessary. After all, why not just use the IP address obtained in the last step as the device name? IP addresses may change over time, and network location and IP addresses are not a convenient form for people to remember or recognize devices. In other words, you need to assign locally unique names and not use the automatically assigned IP addresses for the following reasons:

• The IP address provided may be temporary . If you are communicating with a device at a given address, it is quite possible that, at a later time, the device may have a different address. Attempting to contact the device by connecting to its old address will not succeed. Even worse, that address could be reused by a different device, so when you attempt to connect to it, you may apparently succeed, except you're not actually communicating with the device you intended.

• With mobile devices and devices connected to many networks, the device cannot expect to keep the same IP address in every location and on every different network. In a world where IP addresses are fluid and changeable, having a persistent name that's relatively much more stable is a big benefit. Of course, names also have to be uniquetwo devices cannot have exactly the same namebut the space of all possible names is so much larger than the space of possible IP addresses that coming up with unique names is relatively much easier.

• An IP address is not a human-friendly way to locate a device providing a service. When we want to use a web browser to visit Apple Computer's web page, we type www.apple.com and not a dotted-decimal IP address. As the world moves to IPv6, this problem becomes even more acute. An IPv4 address is just four decimal numbers, such as 17.112.152.32, which is just about possible to remember, if absolutely necessary. An IPv6 address is 32 hexadecimal characters, which is a different story altogether. Most people don't pick secret passwords that are hard to remember, not even for their most important financial accounts.

• If you need to select a device from a list of available devices, this is easier to do if the list is presented as text-based names and not a collection of IP addresses. This is similar to the previous point but is the other direction of recognizing a device, as opposed to requesting that device.

In this chapter, local refers to devices on the same link. You can think of this in a geographically local sense. There are also people with whom you interact every day. If you work remotely, other members of your team are closer to you in some sense than the person you've never met who is working a couple of tables over from you at your neighborhood coffee shop. These remote-but-close devices cannot have a link-local address that carries any meaning. Their name must also be somehow globally unique and not just locally unique. In Chapter 5, you will see how Zeroconf's local technologies can be extended for people and devices that are not on the same link as you. In this chapter, the discussion is restricted to finding a locally unique name using Multicast DNS.

When it comes to global networking today, nothing beats the global domain name system (DNS). However, the power of the global DNS doesn't come without a price. Someone has to set up and run the DNS servers, and the globally unique names have to be assigned, allocated, and managed, usually with money changing hands. For global communications, it's worth all that effort, but if all you want to do is print on a network printer across the room, surely there must be an easier way. When all you need to do is establish names that are valid for the local link, link-local Multicast DNS (mDNS) provides a simple, no-fuss solution.

Instead of relying on a centralized authority, mDNS allows each machine to answer for itself. When a client wishes to do a query, instead of sending it to a particular DNS server, the client sends it using IP Multicast, which means that, a bit like a broadcast, it goes to every interested machine on the local network. Each device on the network runs a little piece of software that's listening for these multicast queries, and, when it sees a query for its own name (or other mDNS data it knows), it answers that query, much as a conventional DNS server would have done. On Mac OS X, this little piece of software is called mDNSResponder . On Windows, it's mDNSResponder.exe. On Linux and similar Unix systems, it's usually called mdnsd.

In this chapter, you will see the details of how to claim a locally unique name in much the same way that you claimed a locally unique IP address. Within a domain intended for this purpose, you choose a name and ask if anyone is using it. If no one is, then you claim and defend this name on the local network. If the name is in use, you choose a different name and repeat the process. The goal with mDNS is to have a system that requires minimal administration and configuration and that works when DNS is not available. We begin the chapter with a look at how DNS works.