Where Everybody's Crazy

Recently, I seem to have knackered my OS X installation; changes I make in System Preferences no longer affect the rest of the system. This is a pain, since I need to go around various places connecting to their networks and getting work done. Here are some of the things that I've found useful while hacking the network preferences.

First thing to note is that you can, of course, configure the basics - IP address and routing - using the standard Unix network tools. The one thing that will drive you mad until you work it out is how DNS lookups work.

The resolving in OS X post-Panther happens in two distinct parts: some things look at /etc/resolv.conf as you'd expect, but some things don't. These things look at lookupd, which is kind of the Mac nsswitch equivalent. We can look at its configuration here:

% lookupd -configuration
...
MaxIdleServers: 4
MaxIdleThreads: 2
MaxThreads: 64
TimeToLive: 43200
Timeout: 30
ValidateCache: YES
ValidationLatency: 15
_config_name: Global Configuration

LookupOrder: Cache FF DNS NI DS
_config_name: Host Configuration

...

The configuration consists of several sections, each ending in the _config_name tag. The one we're interested in is "Host Configuration", since that tells us how hosts get looked up. configd uses a number of "agents" that it consults in order to look up a host, user, or whatever; in this case, it looks up hosts in its own cache, then FF (flat files), then DNS, then NI (NetInfo) and then using DS (Directory Services). This is the default order of lookups - we don't actually need all of those agents, so we can speed up failing lookups by creating a file /etc/lookupd/hosts like so:

LookupOrder Cache DNS

A quick HUP of the lookupd process, and we're now using its internal cache and DNS. Note that lookupd doesn't specify how it uses DNS. We'll come back to that.

We can test that lookupd is giving the right answers by running lookupd -d - this is a handy debugging tool with tab completion and everything:

% lookupd -d
lookupd version 335 (root 2004.06.12 23:14:26 UTC)
Enter command name, "help", or "quit" to exit
> hostWithName: alibi.simon-cozens.org
Dictionary: "DNS: host alibi.simon-cozens.org"
_lookup_DNS_domain: simon-cozens.org
...

Hoorah, we found it. However, if it seems to hang when you press return after the host name - which it probably will if you're reading this because you can't get DNS working - then it's having problems looking things up in DNS.

lookupd is not one of the things that uses resolv.conf to find the DNS server, so what you put in there is irrelevant. You could try the second place that OS X keeps configuration data, in NetInfo; you can dump data in resolv.conf format:

% nidump resolv.conf .
domain simon-cozens.org
nameserver 127.0.0.1

(I find that using a local nameserver, by turning "-ON-" DNSSERVER in /etc/hostconfig is easier than running around trying to find where the nearest nameserver is as I move from place to place, especially since changing the name server is tricky if System Preferences is broken - as we're finding out.) But, maddeningly, you can't load stuff into NetInfo in that format. It turns out that you don't need to, since OS X keeps resolver information in a third place as well, but for the sake of fully documenting what's going on, the next stage is to create locations/resolver in netinfo if it doesn't already exist (yeah, I funted my NetInfo database as well) and then populate it with the right data:

% niutil -create . /locations/resolver
% niutil -createprop . /locations/resolver nameserver 127.0.0.1

Now we have played with lookupd and NetInfo, and probably you're finding that DNS still doesn't work. So it's time to move on to configd. configd is the thing which takes notifications from various parts of the system about configuration changes, and then fires off notifications to things that want to know about this. For instance, battery status events come from the kernel and get dispatched to things which put up that annoying "you're now running on reserve power" dialog.

What happened in my case was that configd stopped listening to System Preferences, so changes to the network configuration never got propagated to things which wanted to implement them. So we have to change the configuration by hand. If you're lucky enough that you have enough Locations set up to do what you want, you can use the scselect utility to change location:

% scselect Automatic

(This is the only way I know of to make DCHP work nicely when everything else is broken.) But if not, you're going to have to get hands dirty and change the configuration manually. We do this with scutil.

# scutil 
> open
> list
  subKey [0] = DirectoryService:PID
  subKey [1] = Plugin:IPConfiguration
...
  subKey [28] = Setup:/Network/Service/5CD6D0CE-E761-11D7-9AA7-0003935B54F8/DNS
...
> show Setup:/Network/Service/5CD6D0CE-E761-11D7-9AA7-0003935B54F8/DNS
<dictionary> {
  ServerAddresses : <array> {
    0 : 192.168.0.1
  }
}

Ooh no, we don't want that address. We want to change it to 127.0.0.1:

> get Setup:/Network/Service/5CD6D0CE-E761-11D7-9AA7-0003935B54F8/DNS

> d.remove ServerAddresses
> d.add ServerAddresses * 127.0.0.1

We need that "*" because ServerAddresses needs to be an array.

> set Setup:/Network/Service/5CD6D0CE-E761-11D7-9AA7-0003935B54F8/DNS

This sets the dictionary d back to the DNS configuration for our current location. Another HUP of lookupd, check /etc/resolv.conf, and DNS should be working for you - if not, you've got a few more places in OS X to play with than you had before. I have yet to explore what else can be done with scutil and playing with configd.