So as host, ping, nslookup, dig etc don’t use the same resolver path as the rest of the OS, we used to always use lookupd for this.
It’s not exactly the most obvious solution in the world, but since lookupd, netinfod and memberd were all rolled into DirectoryService in 10.5, we now use dscacheutil to do this.
$ dscacheutil -q host -a name www.google.com
name: www.l.google.com
alias: www.google.com
ip_address: 74.125.19.104
ip_address: 74.125.19.147
ip_address: 74.125.19.99
ip_address: 74.125.19.103
This is a much more appropriate way of debugging host problems if the *nix tools aren’t showing any problems but OS X components are.
This will fetch the result from the cache, and if it’s not there, fetch it and place it in the cache. If you want to make sure this is a fresh request, do:
dscacheutil -flushcache
and you can always do this:
dscacheutil -cachedump -entries host
to inspect the cache for hosts.
I was actually debugging a Mobile Account problem the other day where the user agreed to create a mobile account at the loginwindow, and yet it kept logging them in with the network account.
Inspecting the DirectoryService cache with:
dscacheutil -cachedump -entries user
showed that the /Local/Default entry for that user was never retrieved. Flushing the cache fixed it.
Turns out the user said no to creating a Mobile Account once, and then logged out without rebooting (and didn’t tell us they’d said no ;-) ). OS X kept the cached entry around and failed to update when creating the Mobile Account as it should have.
Need to get that one into radar….