[NTLUG:Discuss] Dynamic Clients & BIND

[Rob Apodaca]

> Currently;
> 
> Internet --- eth0 -- Firewall -- eth1 -- Clients
> 
> eth0 - Address is dynamically assigned by ISP via DHCP, and includes DNS 
> servers.
> eth1 - Static internal address, with BINDv9 running on it.  DHCP server 
> for clients.
> Bind on eth1 does not get name server info dynamically from DHCP, and 
> therefore is not currently serving up responses to DNS requests.
> (Implication is correct, clients are not currently accessing internet 
> using DNS/IP Lookups).
> 
> Firewall - DHCP server for Clients on eth1.
> Firewall - BIND server for Clients on eth1
> Firewall - DHCP Client on eth0 for connection to internet, gets IP & 
> Nameserver IPs from ISP.
> 
> Problem: eth0 is;
> 1) Dynamically assigned
> 2) Has nameservers changed on a frequent basis
> 
> Question:  How do I tell bind to use the current resolve.conf file's 
> listed nameservers (or nameservers provided by ISP) as the nameservers 
> it is supposed to use?  There is a "Dialup" option for named.conf, is 
> that involved somehow?
> 

I think what you want to do is set up BIND on the firewall to act as a
fowarding, caching nameserver. Then configure your dhcp server to hand
out the IP for eth1 to your clients. Check tldp.org for setting up a
fowarding, caching nameserver.

The process works like this:
1. Client needs to resolve a name (ie google.com).
2. Client checks for a nameserver to use...your firewall eth1 IP
3. Client contacts firwall IP and asks for the IP address of google.com
4. Firewall nameserver uses its configuration to find the address.
5. Firewall returns IP address for google.com to client.
6. Client has resolved google.com to an IP and connects.

You will find that running a caching nameserver has an added benefit -
web pages load quicker due to the fact that once a user resolves a name,
your caching nameserver holds onto the information resulting in a faster
response for subsequent queries for the same name. For example, using
the 'dig' utility to lookup 'somewhere.com', I see that it takes 125
msec to resolve the name the first time. When I run 'dig somewhere.com'
a second time, it only takes 3 msec...because my caching nameserver
already knew the answer (from the first query) and handed it right back
to me instead of going out to the internet searching for it. In addition
to the perfomance gains, you are being a good 'net citizen' by not
making so many uneeded queries from your network to other nameservers
and root nameservers.

The trouble is going to be how to update the fowarding nameservers in
named.conf with your ever changing ISP nameservers (why your ISP doesn't
have fixed addresses for nameservers is baffling). You could write a
script which parses /etc/resovle.conf, grabs the nameservers, updates
named.conf, and restarts bind. I think there is some way to fire off a
script every time your dhcpc on the firewall detects changed
information.

Perhaps an easier way would be to use some other fixed nameservers. My
ISP's nameservers are slow and generally suck, so I use Sprint's
nameservers as forwarders; 204.117.214.10, 199.2.252.10 - which allow
dns queries from anywhere.

A few notes...
1. It's a good idea to configure your firewall to not allow DNS queries
from eth0.
2. You can even have the firewall restrict clients from performing dns
queries to anywhere exept your fireall.
3. Mentioned above, install 'dig' (part of bind-tools package from
isc.org) on an internal machine. This will help you debug name
resolution problems.
4. It does not matter that you have a dynamic public IP on eth0.

Hope this helps.
Cheers,
-Rob