Blog of Wade Making Connexions

Leopard DNS Aiport Issue - Why + Fix

Like planes, every networks is slightly different. Using the same Laptop with the same version of Airport Express, both times at Jelly I found myself unable to connect to Google Talk, yet have no problems at home.

I’d heard a bit of talk floating around about a DNS issue trying to access git, but thought nothing of the relation. I’d spent the morning feeling pretty out of the zone, and haven’t tackled any networking issues in a while so this was a fun afternoon challenge.

What I found was that making DNS requests for SRV records, when using the Airport as the DNS server, the request times out.

Gratuitous-ARP:~ wadem$ dig _xmpp-client._tcp.gmail.com srv @10.0.1.1
;; connection timed out; no servers could be reached

Using the same query, but using the DNS server that the boys put in place to connect to git, allowed me to get the srv query response.

Gratuitous-ARP:~ wadem$ dig _xmpp-client._tcp.gmail.com srv @203.2.75.132
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 5
;; ANSWER SECTION:
_xmpp-client._tcp.gmail.com. 9680 IN SRV 20 0 5222 talk4.l.google.com.

The fix is to use your ISP’s DNS server in the Airport, or put the ISP’s DNS server in your /etc/resolve.conf.

I’m unable to find out what’s going on between the Airport and the Router, and why it fails to proxy the SRV request through correctly. To figure this out, I’d have to re-build my network to bring the issue to light. Not going to happen.

The reason why this issue doesn’t happen on my network is because my DHCP addressing is done at a centralised point, my router. The DNS server given via DHCP is the ISP’s DNS server straight up, no internal DNS-Proxy is done.

Whilst investigating, all of this Tim mentioned he’d determined the problem isn’t Leopard specific, but something to do with what his guess was libcurl.

A little bit later and it turns out Leopard’s changed “The DNS resolver to first attempt SRV requests for lookups initiated by the getaddrinfo() function.”, which is what happen to be what is used by libcurl to do address resolution.

What’s interesting here is that “Leopard is using the latest IETF recommendations for DNS lookups“, it just happens to be bring the DNS server problem to the surface. The IETF recommendation for this style of lookup was published on the standards track in 2000. I wonder why Apple waited 7 years to convert?

Now we know the cause of the problem, the fix, and the reason for the change.

Update 5th June: Thanks to all the readers coming through from Craig Hunter’s Blog. Enjoy your stay.

Nice fix & writeup Wade!
I happened across the turn of phrase “Yak Shaving” (http://en.wiktionary.org/wiki/yak_shaving) which seems perfectly to sum up that whole process of upgrading X11 to install wireshark to analyse the network. Heheh…

Thanks for the comment Lachie. Was glad to get to the bottom of this one. Yak Shaving without getting a result would have sucked.

Also thanks for adding the back story that I somehow forgot to post about. Wonder why that was…:P

Why on earth you were looking at Yak Shaving, I don’t want to know. Regardless, you’re correct, that’s exactly what it felt like :/

Peace,

Wade

PS Nice to see you on OpenID

Just an asside, while my macbook and wifes ibook G4 really works well with 10.5.3 for me it broke my intel core duo Imac. First I had lots of slowdowns/hangs in safari and then after 24 hours I lost internet connectivity completely in the iMac. The only way i could finally get back was to restore from an earlier image of 10.5.3 24 hours before. But my safari quickly is starting to exhibit same symptoms and I supposed it will again loose connectivity. I have a time capsule hooked to a comcast cable modem (all other machines work fine wirelessly with 10.5.3 and this setup — just iMac has problems).

Russ Jacobson

I had the same problem and did a locate on resolv.conf. The only result that came back was /private/var/run/resolv.conf. Dig really wants /etc/resolv.conf so I made a symlink which resolved the problem for me.