The Fugue Counterpoint by Hans Fugal

15Jan/090

VPN DNS

I have a VPN and a DNS server that serves up forward and reverse DNS for my VPN hosts, which zone I call wan. When I want to look at my Cacti graphs, I go to gwythaint.wan and as long as my laptop is on the VPN I can see them wherever I am. In theory anyway. In practice, getting this to work without screwing up other things is harder.

I'll leave out the myriad permutations that I tried over the past couple of weeks and show you the one that actually works well. That is to have a caching and forwarding name server on your laptop, and to add localhost to your list of nameservers. For best results, you would have it forwarding to the name server your DHCP server gives you, with an explicit forward over the VPN for the wan zone (and its reverse). resolvconf on Linux can do this. Your situation may warrant a static forwarder for non-wan addresses, in which case you just set that forwarder and be done with it. If your various DHCP nameservers are a bit more subtle—perhaps serving up internal domains of their own—then you may have to not forward and/or recurse except explicitly for wan.

I just took the default BIND9 configuration on my system and tweaked it thus:

// local/vpn stuff
zone "wan" {
    type forward;
    forwarders { 172.17.77.1; 172.17.0.1; };
};
zone "17.172.in-addr.arpa" {
    type forward;
    forwarders { 172.17.77.1; 172.17.0.1; };
};

On most systems the default named.conf is already some reasonable caching setup, so you wouldn't have to tweak it beyond that. Then I added localhost to the nameserver list (/etc/resolv.conf on Linux, in the network preferences pane on OS X) and checked that it works with a dig @localhost gwythaint.wan.

Things got tricky because dig and host on my laptop were taking forever to
return when I queried localhost—6 seconds or so. I chased this wild goose for
awhile and in the end I didn't find the reason (it still does it), but I
verified that it's not a problem. If you use the -v flag to host you notice
that the actual queries took <1ms, so whatever else host and dig are doing may
not be relevant. Even stranger, if you do host -v gwythaint.wan and don't
specify to query localhost, everything resolves instantly and yet it reports
that it queried localhost (which you can verify with the non-traffic on repeat
requests via tcpdump). It hasn't slowed down any other applications (a 6-second
slowdown on DNS lookups would be very obvious), so I chalk it up to "who
cares?" If host and dig on OS X return the right answer, and you verify they're
querying the right server, then you're good to go.