OS X nslookup
Yesterday I finally switched from a Cisco add-on VPN to the built-in VPN support in Snow Leopard. The built in stuff is much nicer. Easy to use, performant. I had, however, a little hitch along the way.
I have a Windows VM running on the Mac on which I do all my dev builds. My dev machine is a Macbook Pro. I run VMWare Fusion, in unity mode, and life is generally good; it’s a very nice cross targeting solution. The hitch was that when I switched VPNs, DNS no longer worked from the Windows VM for names inside the VPN target domain(s). Lee is my go-to guy for problems like this, and he and I spent quite a while poking around at it. We learned interesting things about the differences between how the two different VPN clients effected their support. They were quite different in how they altered the lookup flow. I won’t go into it, because it’s irrelevant to the posting, really. In the end it turned out that my DNS problems were due to being on an older version of VMWare (version 2). I’d been meaning to upgrade for a long time, but held off, because I never like to upgrade when I’m in the middle of things, lest my world come unglued. Unfortunately, I’m always in the middle of things. Anyway, I upgraded, and things were good again.
Now, about nslookup, which is in the title of this post, in case you hadn’t noticed. Well, Lee and I use nslookup pretty commonly on various platforms to make sure that things are resolving the way they should. We spent quite a bit of time using nslookup yesterday, and we kept being really confused by the results. Eventually, Lee strolled across the street to the coffee shop (I prefer Peet’s coffee, and this wasn’t Peet’s) to poke around from an external network to more closely match my setup (I’m in Massachusetts, he’s in California). Around the same time, we both started being really suspicious of the results from nslookup. And the punchline of the whole thing comes from the man entry for nslookup on OS X:
Mac OS X NOTICE
The nslookup command does not use the host name and address resolution
or the DNS query routing mechanisms used by other processes running on
Mac OS X. The results of name or address queries printed by nslookup
may differ from those found by other processes that use the Mac OS X
native name and address resolution mechanisms. The results of DNS
queries may also differ from queries that use the Mac OS X DNS routing
library.
When they say the results may be different from other processes, we’re talking things like ‘ping’. Sigh.
Mind yourselves out there, there’s gears and stuff you can catch your clothes on.
Share This | Email this page to a friend
Posted by Eli Boling on February 11th, 2011 under OS X |

RSS Feed

February 11th, 2011 at 11:08 am
There are similar situations under Windows; name to IP resolution may go via LMHOSTS / NetBIOS, and the selection and order of connection suffixes may give unexpected results. I have to use ‘.’ as a DNS suffix on my network connection (Windows 7) to be able to reach my Nexenta/Solaris NAS without having to refer to it as ‘rupert.’ instead of ‘rupert’ whenever I need to. I’m using DNSMasq running on an Eee PC (701) for DNS, DHCP etc. as part of my home routing setup, and it could resolve "rupert" just fine vias nslookup.
Basically, nslookup is at too low a level in the stack to expect it to exactly match how programs resolve addresses with getaddrinfo etc. The algorithm used by the OS will usually at least rotate through DNS suffixes and DNS servers, as well as other name resolution systems (I’d hazard a guess that OS X is also using Samba’s nmbd or moral equivalents to interoperate well); meanwhile, nslookup just sends a single explicit request to the default (or selected) DNS name server.