Split DNS?

[Steve Kay]

-----Original Message-----
From: 	kcd at daimlerchrysler.com [mailto:kcd at daimlerchrysler.com]
Sent:	Wednesday, July 19, 2000 4:54 PM
To:	bind-users at isc.org
Subject:	Re: Split DNS?

There is partial support for this in BIND 8. Run 2 instances of named on the
box, with different config files. Use the "listen-on" option to specify that
the "external" instance listens only on the external interface, and the
"internal" instance listens on the internal interface and the loopback
interface. Configure separate "pid-file"s so they don't step on each
other's.

My Question:

Has anybody run into problems trying to run a Split DNS setup under W2K?  I
am running BIND 8.2.2_P5 and am wondering if there is any problem running
two instances (services) in order to create a Split DNS setup.  I have been
reluctant to do so until I know that two servers can coexist.  I know I can
setup a virtual Ethernet port for the internal DNS server to listen on, but
I was afraid of the two daemons stomping on each other in some other shared
resource way.  Any suggestions, caveats, words of warning?

Thanks,

-Steve
Steve at SpatialTech.com


Rob Egan wrote:

> Hi,
>
> I'm building new primary nameservers for both our internal private
> (192.168.1.*) network, as well as for our external network housing our web
> servers etc. I'd like to combine these onto a single machine (forcing the
> nameserver to return internal records to queries originating from our
> internal network, and external records to queries originating elsewhere).
> Can I accomplish this using "split DNS" and if so, does BIND 8.2.2_p5
> support this feature?

Also, if you use "ndc" to control your nameserver instances, they'll need to
be configured with separate channels. Ideally, your external instance should
shut off recursion and only allow queries in domains for which it is
authoritative -- this is desirable both from a security standpoint and to
limit the CPU and memory usage of the external instance.

As for zone configuration, configure both instances with an Internet hints
file. (This is rather redundant when recursion is turned off for the
external
instance, since then it'll always be answering from authoritative data, but
you have to humor named with a hints file anyway, so why not just use the
same file?) Define all of the zones you want to host externally on the
external instance and optionally, any zones you are going to slave. For the
internal instance, define at least the apex zone of *every* internal domain,
e.g. "foo.com", "bar.com", as either master, slave, stub or forward. This
will ensure that internal clients querying that instance will always get
answers from the internal versions of your zones. The firewall's resolver
would be configured to use loopback, so that it is able to resolve both
internal and external names. Note that if you have zones which you want
served on both the inside and outside, with different data (usually the
external version is a "shadow" subset of the internal), then you have to
maintain the zone data in *both* places.

There is one important decision you have to make. What kind of response
should your internal clients get if they query an external name? If you're
behind a "proxy"-type firewall, the internal clients generally don't *need*
to be able to resolve Internet names, and if such names do happen to resolve
from the Internet DNS, this can cause problems, particularly for MX-routing
mail servers (since then they'll try unsuccessfully to deliver mail directly
to external addresses). You could run an "internal root" architecture, so
that these external names simply appear, to internal clients, to not exist.
You can also put wildcard MX records in your internal root zone to ensure
that MX-routed mail is forwarded to an Internet gateway. But you can't run
this internal root on the same instance that the firewall is using for its
resolution, since then it would prevent the firewall from being able to
resolve Internet names -- it would have to run as a *third* instance on the
firewall, or on a separate machine. Alternatively, if you have a
"routing"-type firewall, or you have only static, i.e. hard-coded routing
for
protocols like mail, then maybe you don't care whether your internal clients
can see the Internet namespace or not. You have to decide one way or the
other though.

The "views" mechanism in BIND 9 should make all of this easier to maintain.
By allowing you to specify which versions of zones to serve to which
clients,
it should cut down on the number of instances required to support "split"
DNS
and/or the number of places where the same data would need to be maintained.
I can't give specifics, though, since I haven't really gotten around to
playing with "views" yet...


- Kevin