Section 3.2. The Zeroconf Namespace

3.2. The Zeroconf Namespace

When you want to run a global web server that's reachable from anywhere on the planet, you need a globally unique name that's resolvable from anywhere on the planet. However, if you're setting up a web server that's only used locally, then it would be nice if you didn't have to incur all of that overhead. Running a web server on Mac OS X is as simple as just clicking one checkbox, so it would be nice if getting a name for that server were as easy. As shown in Figure 3-3, you check the Personal Web Sharing checkbox to start up the Apache web server.

The content of the computer's web site is contained in the /Library/Webserver/Documents/ directory. The index.html file will appear when the browser is pointed at the provided IP address. In addition, each user can have a personal web site that is accessed using the IP address followed by ~username/. The pages being served are in this machine under the ~username/Sites directory.

Note that, in the Figure 3-3, the displayed URL contains an embedded IP address. This is not very memorable, nor user-friendly, and because it's a DHCP-assigned address, it may well be different tomorrow. What we need is a memorable, stable name in place of this IP address.

Figure 3-3. Starting the Apache Web Server on Mac OS X

3.2.1. The local Domain

In order to distinguish local names from existing domain names, Zeroconf uses .local. as a pseudo-top-level domain (TLD). Just as IP addresses beginning with 169.254 are deemed special, not globally unique, and therefore only meaningful on the local link, names under the pseudo-TLD "local" are similarly deemed special, not globally unique, and only meaningful on the local link. The benefit of local names is that you don't need an arbiter who hands out names and you don't have to pay money for them. The drawback of local names is that because there's no arbiter and you didn't pay any money for your name, you can't claim unique ownership and prevent others from using that same name if they want. Instead, devices using local names have to follow a set of cooperative rules (i.e., protocol) by which they detect if two devices try to use the same name at the same time, and, if this happens, one of them voluntarily selects a new unique name. You cannot assume, if you see the name example.local. on a given link, that it has any relationship to an example.local. that you see on a different link, nor can you assume that it has any relationship to an example.local. you may have seen before on the same link. Of course, you should pick a name that is personalized to help others who know you have a chance of finding and identifying you.

The easy changeability of names may seem to some to be a big potential security weaknesswhat if I'm not really printing on the printer I intended? In reality, however, IP addresses and even Ethernet hardware addresses can be spoofed. The only sound way to provide assurance of identity is by end-to-end cryptographic means. For example, when you connect to a host for the first time using the ssh (secure shell) remote login command, that host's public key is saved for future reference in your .ssh/known_hosts file. Each subsequent time you connect, the host's identity is verified cryptographically using the public key you saved, and if you ever inadvertently connect to an impostor host that doesn't have the correct secret key matching the public key you previously saved, then ssh will display an error message telling you so and will refuse to complete the connection.

Names in the pseudo-TLD local are always looked up using multicast , but what about other names? Standard DNS names are normally looked up using unicast queries sent to a normal DNS server. (Unicast packets are the standard type of packet usually used on the Internet; they go to a single destination machine, as opposed to broadcast or multicast packets that are delivered to some collection of machines.) However, when the Internet link is down, or the DNS server is not responding for some other reason, this leaves all these names unresolvable. You may be trying to connect to tim.oreilly.com, sitting right next to tim.oreilly.com, but you can't connect because your Internet link is down and you can't reach the global DNS. (There's an old joke that network computing means "You can't get your work done because of a problem you don't care about with a computer you've never heard of in a building you've never been to.") In this situation, a client could choose to multicast its query locally, so that the two computers can communicate directly, peer-to-peer, and set up a connection without reliance on the external DNS. Even though the peers cannot communicate with the global DNS, they would still be using their usual global DNS names to refer to each other. While it is clearly useful, it also makes spoofing easier. The machine next to you may claim to be tim.oreilly.com, but how can you be sure? This risk could be mitigated by using cryptographic techniques like the ones described above used by ssh, but much of today's application software doesn't implement such strong security measures. In the future, when better security mechanisms are in place, it may become practical to begin using local mDNS as a fallback mechanism to look up global DNS names when the global DNS is inaccessible, but for now, it is safest to restrict mDNS for use with dot-local names.

Names on Intranets

There's no end of names that can be chosen as a TLD for private DNS namespaces. For example, you could choose .intranet, .internal, .private, .corp, or .home. In "How to create local DNS names" (http://cr.yp.to/djbdns/dot-local.html), author D.J. Bernstein recommends using .0 through .9 as safe top-level local names. You should avoid .local. because it has been used in Mac OS 9 and Mac OS X for a long time to identify a name as being link-local, and now with Bonjour for Windows and Multicast DNS for Linux, .local has special meaning on those platforms also.

3.2.2. Choosing a Name

If you are the administrator for a domain such as example.com, you can choose any name for a device and assign it and register it; e.g., you may choose printer.example.com. However, most of us don't have the luxury (or burden) of administering our own DNS domain. The impediment is not merely the financial cost of paying for your own DNS domain, but also the organizational overhead of getting it properly delegated from its parent domain and the technical burden of running a name server or getting someone else to do it for you. None of these problems is really that big, and many computer enthusiasts do run their own domains quite successfully, but the fact remains that the majority of Internet users have no idea how to do this, or even that the option is available to them. Also, even if you're the kind of person who can set up a working name server with just half a day's work, there are many situations where even that level of effort is not justified. There are many situations where all you need is some temporary communication between a couple of devices, and you want to do it with just a few seconds of effort, not a few minutes or a few hours. Zeroconf provides this "system administration for the rest of us."

As shown in Figure 3-4, you can set your computer's "dot-local" hostname by clicking the Edit...button in the Mac OS X 10.4 Sharing preference pane.

Figure 3-4. Choosing a dot-local hostname for your computer

Once you have made the change shown in Figure 3-4, devices on the local link can refer to your computer by the name mymac.local. This name can be used anywhere a normal DNS hostname would be usedsuch as on the command line (for example, ping mymac.local, ssh mymac.local, ftp mymac.local), in graphical FTP clients, in the Finder's Connect to Server dialog, or in a web browser.

The name mymac.local may not be a particularly good name to use on public local links since it is not likely to be (or to remain) unique. Your name can be fairly long and descriptive; however, well before you hit the formal upper limit of 63 characters allowed for a dot-local hostname, you will get to a length that is difficult to display and for potential users to easily enter. Think of how you currently react to overly long URLs. A good dot-local hostname is memorable, short, and easy to type, but unique enough that encounters with others who've picked the same name should be relatively rare.

The Mac OS X 10.4 Sharing preference pane also has a text field labeled Computer Name, which is actually used to control the default name used for services advertised on your machine. We'll cover more on this in Chapter 4. Generally speaking, you want your local hostname to be short, because it's usually entered by typing it, and you want your default service name (i.e., Computer Name) to be long and descriptive, because advertised services are usually selected from a list of choices by clicking with the mouse, never by typing. Because of this, service names can be as rich as you like, with uppercase, lowercase, spaces, accented characters, and any amount of weird and wonderful punctuation.

If two computers on the same link try to use the same hostname, one of them will automatically rename. For example, if both try to use the name mymac.local, one will automatically rename to mymac-2.local. In Mac OS X 10.3, this change happens silently, and the user is not informed. In Mac OS X 10.4 and later, the system puts up an alert to inform the user of the name change.

In principle, it's possible for each network interface on your computer to answer to a different name, or even for a single network interface to answer to a variety of different names. But in practice, this would be confusing, so Mac OS X uses a single hostname for all its interfaces.