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 @188.8.131.52
;; 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.