Split DNS?

[Kevin Darcy]

Rob Egan wrote:

> One of my goals for using split DNS was to avoid
> having to make updates to DNS records on two machines. However, split DNS
> still requires updates to two sets of files whether there on one machine or
> two. Does the support for split DNS in BIND 9 alleviate any of this?

Hmmm... Looking more closely at the documentation, it appears that "view"s
allow you to answer differently for the same zone depending on who is doing the
asking, but this is only on a zone-by-zone, rather than an entry-by-entry basis
(see doc/misc/options and the section on "views" in doc/arm/Bv9ARM.6.html in
the BIND 9 tarball). This should allow you to reduce down to 1 instance if
you're only supporting external access and firewall-resolver access. If you
want the box to host an internal root for internal clients, though, you'd still
need to run an additional instance, since you can't feasibly have a "view" for
every Internet zone you learn about via referral. In and of itself, though,
"view"s don't seem to obviate the need to maintain 2 different versions of the
zones in question. Perhaps someone more familiar with BIND 9 "view"s could
confirm or deny?

Note that this implementation of "view"s -- assuming I have understood it
correctly -- differs from what was envisioned in the _DNS_and_BIND_ book (see
page 393). *That* implementation would have obviated the need for double
maintenance by implementing true *conditional* forwarding, i.e. forward the
query if I don't have the name in my authoritative data. It would, however,
have required multiple instances to work -- the internal instance, and the
external instance to which it would conditionally forward.

If your firewall is master for both versions -- internal and external -- of a
zone, I suppose you could play $INCLUDE tricks to save yourself some double
maintenance. This of course has nothing to do with whether you're running
BIND 8 or BIND 9; it's just a thought that occurred to me.

> Also, where is everybody learning about split DNS? I have the 3rd edition
> DNS and BIND O'Reilly book, and I read about BIND 8 and 9 on the isc.org
> website, but I've seen no mention of split DNS (other than the fact that
> it's a feature in BIND 9).

There's a heading on "shadow namespaces" starting page 394 (in the "DNS and
Internet Firewalls" section), which implicitly describes a particular
implementation of split DNS. This implementation isn't the "two-headed" variant
that I described to you, though (you had specifically asked about running
multiple instances on the same box). There is, of course, more than one way to
do split DNS. I prefer to run "two-headed" here because it concentrates the
ugliness mostly just on the firewalls, allowing all of my internal servers to
form a "pure" internal-root architecture, complete with TLD wildcard MX records
for outbound mail routing. (As you may have guessed, we run "proxy"-type
firewalls here).


- Kevin

> > -----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?
> >
> >
> >
> > 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?
> >
> > 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.
> > 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
> >
> >
> >
> >
> >