Automountd trying to connect to Backups.backupdb

An explanation of why automountd is trying to find Backups.backupdb on the Internet…

I woke up this morning with a warning from Little Snitch outbound firewall that automountd wants to connect to Backups.backupdb on port 111.

Here’s what I’ve discovered since then.

automountd is a system service which mounts and unmounts network file systems (NFS) and lists contents of directories when requested (i.e. makes them accessible for use, like double clicking a .dmg file on your desktop, after that you can access the disk image).

Backups.backupdb is the Time Machine directory which contains your backups, usually on an external USB drive connected to your Mac.

When Time Machine is scheduled to do a backup, it tries to make a connection to Backups.backupdb to read its contents, which is automountd’s job to handle.
automountd pokes around, doesn’t find the directory within its network file system maps (when the external backup drive is not connected) and asks Open Directory/Directory Services “Yo, where’s Backups.backupdb?”

Directory Services stares at automountd blankly for a few moments and decides to check with DNS.

Directory Services asks the DNS server, “hey, you know where I can find Backups.backupdb”, to which your DNS server (located at your ISP or OpenDNS) will answer “Dood… that’s a nxdomain (non-existent domain) BUT, I’m gonna return you the address of a website with a bunch of search results and advertising”.

Here-in lies the rub: normally you should get a straight NXDOMAIN response from DNS meaning, there is no IP address for that domain. Instead, a lot of ISP’s (and OpenDNS) have capitalized on this and are returning an IP address to a web server dishing out search results and advertising, rather than a simple NXDOMAIN response. The result of which is applications such as Firefox or Safari, and services such as Time Machine , through automountd, are thinking that they’ve found the right address and therefore use it when handling requests.

The upside of this “service” is that instead of getting a “Website Not Found Error” in a browser, you get a list of possibly helpful search results of what you were really looking for.

The downside of course is that services such as Time Machine, have no idea that the address is not really the location of Backups.backupdb, but is in fact, a location of a website with search results and pay-per-click ads.

So, automountd attempts to read the contents of the directory called “Backups.backupdb” at the address returned by the DNS server, in my case “hit-nxdomain.opendns.com” located at 208.69.34.132, using a remote procedure call (rpc) on port 111. Of course, this remote procedure call will fail since 208.69.34.132 / hit-nxdomain.opendns.com is not a Network File System which accepts requests to mount drives, it’s a website meant for humans to see search results and click on ads.

Solutions to stop automountd from trying to connect to Backups.backupdb over the Internet?

• Leave your USB/firewire Time Machine backup drive attached to your Mac so that automountd can find it without having to ask DNS.
• Add a hosts file entry that maps “Backups.backupdb” to a local address, say 127.0.0.1. A rather crude, but possibly effective solution. I haven’t tried nor tested this solution, so I won’t elaborate on how that’s done.
• Added 080602: If you’re using OpenDNS, they offer a way to exclude certain non-existent domains from being subject to the “search results” page response of hit-nxdomain.opendns.com. Thus, you can add the domain name of “Backups.backupdb” to the Typo Exceptions list and OpenDNS will return a straight NXDOMAIN response when queried for that domain. See the following screenshot for an example. Before adding frankie_valens to the Typo Exceptions list, an A record query to OpenDNS resulted in this response: 1/0/0 A hit-nxdomain.opendns.com (48) which is OpenDNS’ search results page address. After adding the fake frankie_valens domain and retrying the same query the answer is now NXDomain 0/0/0 (32) which is a proper non-existent domain response.

Although I know the first solution works for me, I’d like to call on some autofs experts for advice on how to handle this situation, with a more graceful solution.

Which is what I’m going to do right now and we’ll see what we can work out.

Updates and links to follow.

Update 2008-06-01

I think I’ve found just the right Apple autofs expert, Rajeev Karamchedu, that could help us figure out how to prevent automountd from connecting to spurious websites of search results due to a non-existent domain (NXDOMAIN) response from our DNS service provider, in this case, OpenDNS. Rajeev! Master of all things autofs… care to lend us some expertise on solutions to the above issue?

Related posts:

1. 1.0.0.127.dnsbugtest. 1.0.0.127.in-addr-arpa
2. Firefox 3 Keyword Tag Search with OpenDNS Not Working
3. Slow Internet with Leopard