bind 9.3.2 and split dns
Kevin Darcy
kcd at daimlerchrysler.com
Wed May 24 21:08:51 UTC 2006
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
More information about the bind-users
mailing list