Wide Area Bonjour - Part 1 The Practical Bits

There's been some discussion in the AFP548 forums on the use of wide area Bonjour recently. I must admit that in the past I hadn't had the best of luck with this. However, some people in the forums seem to have done better so over the break I took another look at it.

I'm happy to say that it is imminently feasible to use WAB in a practical that could be very interesting to most organizations. Additionally there is a darker side to it, that's just useful enough to make you angry that it doesn't all work the way it could work.

So read on for the practical part of this, and part 2 will have the darker side.

The Tease of Mac OS X Server

With the introduction of Leopard there has always been a check box in the DNS module of Server Admin that would allow for wide area Bonjour. The box was practically begging you to check it, however, there was pretty much no documentation on what it was supposed to do. Worse yet, when you did check it, not much seemed to happen. No longer... Through hours of painstaking research I think we've managed to suss out what's going on here.

First of all, some background on WAB and what you probably want it to do for you.

Long Live AppleTalk!

Since the overly lengthy demise of AppleTalk there have been a number of people interested in resurrecting at least a part of the functionality that AppleTalk provided. In the days of yore a large number of Apple's biggest customers had set up elaborate AppleTalk zones. Conveniently allowing large groups of machines, in some cases up into the tens of thousands, to be grouped into browsable zones. This made finding the server that you were looking for, in my case the file share in the dorm across campus, much easier. With a bit of network plumbing from your routers, all the machines would neatly announce their presence into just the zone they should be in. It all made sense, and was very easy for the end user to understand.

Well, all good things come to an end. AppleTalk was made the scapegoat of many an anti-Mac pogrom and after a very long and miserable slow death, you have to work quite hard to find any trace of it on a network. Granted, I believe that some of this AppleTalk nostalgia is certainly a symptom of distance making the heart grow fonder, as it certainly did have its downsides as well. The primary one being that AppleTalk was primarily only used by Apple. Cisco and some of the other vendors had support for it at the beginning, but much like IPX and some other "cool at the time" protocols, it become a much bigger liability having to maintain a secondary protocol beyond IP on the network.

The Rise of Rendezvous

With 10.2, while AppleTalk was still limping along on a lot of networks, Apple rolled out its successor, Rendezvous. This was an amazingly clever method of using an IP address space that most people thought was an error condition and didn't have a legitimate network use. That was coupled with some as clever work with DNS records and we were back on track to being able to browse for other machines on the network.

A lawsuit later and the name was changed to the equally francophone Bonjour. Interest continued to pick up as printer vendors and other organizations hopped on the Bonjour bandwagon. This culminated into what we have now in 10.5 where the so amazing it seems like magic technology of Back to My Mac shows what Bonjour is truly capable of when it can fully spread its wings.

And here comes the tease. If you've used Back to My Mac, and you have an agreeable router connecting you to the Internet, you'll be able to find your other machines from anywhere on the Internet. Using Bonjour and some long-lived queries as a beacon home, your Mac will establish an IPSec tunnel, using IPv6 no less, and securely allow access via PKINIT to all of the services on the remote machine. I use BTMM almost daily and find it painful when I have to use a 10.4 box that can't play in the BTMM party.

We'll do a piece on the technology behind BTMM later (it's mostly written so I actually mean this when I say it), but the remote machine registers its external IP address and the services it has available using wide area Bonjour. It's hosted on a private MobileMe DNS domain that you get when you buy a MobileMe account. Other systems register with this DNS domain and, in a very new trick for the old technology of DNS, get automatically updated by the DNS server when anything changes. This is termed a long-lived query and has some very sexy implications, but those we'll be brought up in part two of this series.

So, How to Get This Going

First you'll need a DNS domain. Ideally this is one hosted on an OS X Server or other BIND 9 system. While non-BIND DNS servers may work, you're going to be entering some records that, while perfectly valid, are of a type and size that most DNS servers have never seen before. I'll explain how to do set this up on BIND system here which should give you enough information to be dangerous on any other DNS server.

If you're using OS X Server, the first step is to actually check the box in Server Admin about using wide-area Bonjour for a domain. Note that you need to add a period to the end of the domain name. For the examples here we'll use afp548.com as the domain.

Checking this box adds a record into your zone file.

lb._dns-sd._udp    PTR     afp548.com.

This tells a WAB client that this domain may actually contain WAB records. The unfortunate bit here is that the lb. record is the legacy browse record and you should also have a straight b._dns-sd._udp.afp548.com record. Luckily with OSXS 10.5 you can actually do this without boning your DNS GUI. In /var/named you'll find a zone stub file with the name of the domain. In our example it would be /var/named/db.afp548.com. The only thing in this file is an include statement that points to the zone file maintained by Server Admin in /var/named/zones/.

As long as you leave that line alone, and it's probably best to keep it at the top of the file, you can add any arbitrary record that you want below this. So, add

b._dns-sd._udp    PTR     afp548.com.

Swapping out the IP address for the IP address of your DNS server.

If you're doing this on a stock BIND system, just add the two records into your existing zone file.

Now for the Client

For the client machine to make any sense of these records, it has to know to look in the domain. This is done by adding the domain to the search domain section of your DNS config. You can do this either manually or via DHCP. We'll discuss the practical usage of all this at the end of the article, but it's probably best to put all of this WAB shenanigans behind your firewall and then add the domain to your VPN DNS settings so that clients will only browse it when using the VPN.

You can test to see if this took in a few ways.

1. For the CLI-inclined you can use the dns-sd command.

dns-sd -F

Will return the recommended browsing domains. If you see your WAB domain show up, then you know you've done something right.

2. Use Bonjour Browser. A handy little GUI for sussing out Bonjour registrations. You can pick this up here.

3. Go to the sidebar in the Finder. Under "Shared" click on "All..." and see if you have a globe there with the name of your domain.

Now to Add Some Records

So, this is all fine, but it doesn't do you squat. You'll need to add records to your zone before this becomes useful. For this example we're going to be adding an AFP server and a web site. The end result of this will be a static registration, think of it as a bookmark, of the AFP server in the Finder sidebar and, if you have Bonjour bookmarks turned on in Safari, the web site showing up in your Safari bookmarks.

For each service you want to advertise, you're going to need at least CHECK two new DNS records. An SRV record that identifies the service that will be hosted. And then, and this is where most DNS GUIs will get a bit uppity, a PTR record. While perfectly legal to have a PTR in a forward domain, it's not a common thing to have.

Note: When adding records to the zone file you're going to need to stop and then start the DNS server each time you do this. Additionally you'll need to increment the serial number in the file.

The PTR record maps the type of service being offered, a webpage perhaps, to the "name" of the service. For example

_http._tcp.afp548.com. 10800 IN PTR Great\032Server\032Website._http._tcp.afp548.com.

Would map show up as a Bonjour bookmark for a "Great Server Website" in the afp548.com DNS domain.

This then corresponds with an SRV record that maps this human readable name back into an IP address. Like such:

Great\032Server\032Website._http._tcp.afp548.com.    10800 IN    SRV 0 0 80    www.afp548.com

Furthermore for some services you'll want to add a TXT record as well to add any additional info.

Great\032Server\032Website._http._tcp.afp548.com.    10800 IN    TXT    path=/

By putting all of these into your WAB-enabled DNS domain, you've now got a static bookmark.

Now for a quick AFP server example. We'll start off with the PTR again. It's almost exactly the same, except for we define a different service type that we're offering.

_afpovertcp._tcp.afp548.com. 3600 IN    PTR    Huge\032Server._afpovertcp._tcp.afp548.com.

The service types, and a boatload of other information, is kept at dns-sd.org. Now for the SRV record to tie this back to an IP address.

Huge\032Server._afpovertcp._tcp.afp548.com. 3600 IN SRV 0 0 548 huge.afp548.com.

There is no need for a TXT record with AFP servers.

For the simplest way to look at the syntax of these records, turn on some services on your local LAN. Then use Bonjour Browser to look at how the records are registered.

Back to the Client

At this point, you should be able to go the sidebar in the Finder, select "All..." under "Shared" and see a grey globe for your domain. In here you should find the static entry for the AFP server that you added. If you can actually make a connection to that system, you should be able to select it at this time and see what shares are available.

For some environments this may be all you're really looking for. You can do this with any service that's Bonjour-enabled. So that includes printers, screen sharing, file services and iPhoto, to name but a few. For the more adventurous you can even subdomain the records and put a bit of organization behind all of this.

Practical Use

Since these records are probably semi-sensitive you'd be wise to keep all of this behind closed doors. For machines on your LAN, push out the search domain via DHCP and have them use the internal DNS server where these records are kept. For remote systems, it's best not to expose the WAB records via the public DNS. Instead push out both the search domain and the DNS server via the DNS settings with your VPN. This is cake to do if you're using OS X Server and should be fairly simple for other VPN solutions as well. This setup will allow systems to only get the static records when they're on the VPN, which is probably the only time the links would actually work anyway.

The Tease

Now, admittedly, static records probably aren't exactly what you were looking for. While they can make life easier for your users, as an admin you were probably looking for something a bit more. Something that's a bit more dynamic. This is possible, but it does have some big caveats to it. Read the second part of this series for how to do that.