Friday, 8 July 2011

DNS forwarders

I shouldn't have to do this too often, and to be honest I can't remember what the reason was for the last time I set up forwarders with BIND, but I do remember that I did and that I am again looking up how to do it.

For a remote office I want to set up a caching only name server that forwards lookups onto my ISP's DNS servers, but I also want it to forward requests for the active directory domain onto my central site DNS servers.

Why is this a good idea? It means that the remote office machine use the ISP's DNS for the remote office's internet connection rather the DNS query going down the VPN to the central office's DNS servers, except when we need to. It also means that if for any reason the VPN between the offices goes down the remote office can continue accessing the internet.

Install BIND on Debian with:

# apt-get install bind9

Get BIND to use the ISP's DNS servers

Edit /etc/bind/named.conf.options and add the following line within the options section:

forwarders {;; };

You will need to replace the fictitious IP addresses above with the ones that are provided by your ISP.

Get BIND to forward quires for your active directory domain to your internal DNS servers.

Edit /etc/bind/named.conf.local and add the following lines:

zone "" { type forward; forward only; forwarders {;;}; };

zone "" { type forward; forward only; forwarders {;;}; };

Change the IP addresses and to the IP addresses of the DNS servers that server your Active Directory domain.

And don't forget to reboot your Linux box to test that everything works as expected :D

Always reboot a linux box!

This is something I get caught out with from time to time.

You are not forced to reboot a Linux box as often as some other PC operating systems, for me this is good and bad.

It has been known for me to throw a machine together to solve a 'temporary' problem and not test that it returns to that same state after a reboot. It is all too easy to make the desired changes (iptables entries, NIC settings and routes) and not actually save them in init scripts. When your handy work silently turns from a 'temporary' solution into a permanent solution, and someone reboots the box... well you get the picture.

So if you can, always do a confidence reboot!