Little Snitch reported that automountd was trying to send sunrpc calls to a strange domain when I started iPhoto. Then I noticed that iPhoto was taking a long time to start up, displaying the wait cursor (spinning pinwheel) for almost a minute. Hmm … had my computer contracted some malware?
Turns out, no. The problem was caused by curious iTunes behavior coupled with an annoying DNS server. When iPhoto 8.1.2 starts, it tries to mount IPHOTO.XML and PHOTO_CD (no idea why), and automountd tries to resolve these names to network addresses. Normally, this resolution fails and iPhoto moves on. In this case, however, my ISP was returning addresses for non-existent domains:
$ dig IPHOTO.XML @188.8.131.52 +short
(ISPs like to do this so that your browser will show pages full of ads when you type bad addresses into your browser. They don’t realize that this behavior, beyond being impolite, screws up programs that rely on sensible DNS responses.)
automountd was trying to send NFS pings to the resolved host and giving up after about 40 seconds. Hence the delay. I switched my DNS servers to Google’s Public DNS, and iPhoto started immediately.
But one mystery remained: Why did Little Snitch report a connection to some strange domain and not the IP address or IPHOTO.XML? A reverse lookup on 184.108.40.206 yielded nothing. I can only speculate that OS X uses a local DNS cache for reverse DNS resolution. Lots of domains (all non-existent ones) had resolved to that IP, and the cache somehow picked one. I found some evidence for this hypothesis by restarting the computer. Little Snitch then reported IPHOTO.XML and PHOTO_CD as expected, and a dump of the mDNSResponder cache revealed entries for both “domains.”