For every stupid hard coded Steve Jobism in OS X¹, there’s some really awesome unix extentions I’d like to see elsewhere.  The big one for me today has to do with DNS handling.

I’ve been playing with OpenVPN to get access to my network at home.  Since I have a MacBook Pro from work, that’s been my end point client.  I’ve been using Tunnelblick as my OpenVPN client to connect to OpenVPN server on my linux box (installed via DAG’s RPM repository.)  One thing that bugged me was how to get DNS so I can see my internal home DNS without breaking access to work’s internal DNS.  If I was using a linux laptop, I think my solution would have to do with running a local instance of named with some wacked out config to do caching only and refer to different DNS servers.  Hardly dynamic and a giant PITA to get going.

I was curious about how to make this go though, and what general solutions people had when I came across a post by Mike Erdely titled OpenVPN + DNS + OS X.  That is exactly what I wanted to do!  As a bonus he’s even using Tunnelblick.

Mike shows how OS X’s DNS resolver uses an /etc/resolver directory to get additional per-domain configuration information, as opposed to the blanket /etc/resolve.conf that unix users have come to know.  To get the mac to resolve kgarner.com using my doman’s internal DNS server I just need to create /etc/resolver/kgarner.com and put nameserver 192.168.1.10 inside of it.  This directs OS X’s resolver to ask 192.168.1.10 for any kgarner.com query.  He also shows how to flush OS X’s DNS cache via lookupd so if I had hit any of my public kgarner.com IPs the resolver will send me to the private ip instead of the public one i’ve already hit.  There’s also two simple scripts that you can integrate with OpenVPN to add and remove the /etc/resolver entry as needed.

The fact that OS X’s resolver will check for entries /etc/resolver first is the type of smart unix extentions I’d like to see more of.  There’s no reason Linux’s resolver can’t be doing something like this.  It would make VPNs easier to implement, and doesn’t seem to be that hard to add to the resolver code.

Other examples of OS X moving stuff forward is the init/cron/at all in one launchd.  I’m slowly starting to agree that init, cron, and at are all sides of the same coin.  Don’t get me wrong, launchd has some issues, but the idea is a step in the right direction, especially for machines that will sleep.  A lot of what OS X has done to make unix better is especially for mobile sleep-capable devices like laptops.

¹ Ask MARK for a laundry list of them…  🙂