Split DNS?

Rob Egan rob at artistdirect.com
Thu Jul 20 00:48:56 UTC 2000


Kevin,

Thanks for your reply. 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? Somehow
I envisioned "split DNS" as allowing some way to identify records as those
that should be visible to external hosts, and those that are visible to only
internal users, but all the records exist in a single file (sounds like a
neat idea, anyway).

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

-Rob

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




More information about the bind-users mailing list