bind 9.3.2 and split dns

[Kevin Darcy]

fybar wrote:

>I think that split DNS is the correct term.  I have a FreeBSD server acting
>as a firewall with IPF acting as a DHCP server and I want it to also be the
>DNS server.  I want to configure it to serve internet DNS as well as
>provide dynamic DNS for my internal lan.  Is there a tutorial on how to set
>this up?  I imagine that this is a common config.  Is there an example
>named.conf somewhere that shows how to do this?
>
If it weren't for the DHCP dependency, this would be a fairly 
straightforward config:
1) an "internal" view which would match source addresses in your address 
range(s), recursion turned on, configured with an Internet "hints" file 
and perhaps just some of your own zones hosted authoritatively,
2) an "external" view which would be the "fall through" from your 
"internal" view (i.e. it would match all addresses *not* in your address 
range(s)), recursion turned *off* (for security) and perhaps some 
additional allow-query restrictions, depending on how paranoid you 
wanted to be. All of the zones that you want to serve to the Internet 
would be defined in the "external" view.

However, such a "split" configuration usually has a requirement that the 
external entries, in zones that you use both internally and externally, 
need to be defined in *both* the internal and external versions of their 
respective zones. This is because the clients in the DMZ/Border-Gateway 
itself need to be able to resolve both internal and external names. 
Normally at this point I would mention that you could $INCLUDE a file 
containing these "common" entries into both the internal and external 
version of each respective zone. However, if you want to support Dynamic 
Update for one or more of these zones, then since $INCLUDE isn't 
compatible with Dynamic Update, you'd be stuck with having to actually 
double your maintenance of these "common"entries.

It would be ideal, of course, if you could segregate the Dynamic Update 
stuff into a seperate subzone, e.g. dynamic.example.com or 
dhcp.example.com. But it sounds like you might already be too far along 
to make such a radical change to your naming conventions.

Note that anything that can be done with separate views in a single 
nameserver instance could also be done by running separate nameserver 
instances on the same box (listening on different addresses via 
"listen-on"), or by simply running multiple nameservers serving 
different functions, vis-a-vis hosting versus recursive-resolving. 
Separating the functions into separate instances or servers, results in 
simpler and more straightfoward configurations, and better "isolation" 
in a security sense, but worse resource efficiency, more operational 
complexity, and possibly even more cost, if 
hardware/installation/support/maintenance needs to be procured for the 
purpose.

- Kevin