Split DNS for large organizations

[Kevin Darcy]

Rainer Ginsberg wrote:

> At the moment, only our firewalls know Internet DNS. In the intranet,
> we have our own root name servers. But we use the same domain names
> in the Internet and intranet.
>
> We are now investigating the possibility of using split DNS. Reading
> the book "DNS and BIND" by Albitz and Liu, the only possibility is
> using forwarders. But they also say "forwarding is fine for small
> networks [...], but probably inadequate for large networks [...]."
> As a solution they introduce views, which might be implemented in a
> future version of BIND. Especially the possibility to negate domains
> is what we would need.

> My questions are:
> Will views be implemted in BIND? If yes, any idea when?

I've seen a couple of different answers to this: 1) selective forwarding
(and "de-forwarding", as I call it) is a partial implementation of
views, and is already available, and 2) a full implementation of views
will be included in BIND 9, due to be generally available some time
around the middle of next year (?)

> Or:
> Do other large organizations use split DNS with forwarders?

I know the corporation formerly known as Daimler-Benz did/does, for one.
Maybe you've heard of it? :-)

I'm curious, though, why you would be considering forwarding at all.
You've lasted this long without your internal clients needing to resolve
Internet names, is this suddenly a new user requirement? Are you also
changing your firewall and network infrastructure to allow internal
clients to connect to Internet hosts, and, if not, what's the use of
allowing a client to resolve an Internet name if it can't really do
anything with that information? We -- the former "Chrysler" part of
DaimlerChrysler, that is -- run application proxy firewalls exclusively
and are quite happy with our internal root setup, although we've had to
play some games with TLD wildcard MX records to humor our mail software.
With forwarding, you have scalability, adaptability and robustness
concerns to worry about, because you no longer have the "prefer the
fastest NS" algorithm for referrals working for you anymore. Another
downside with trying to inject Internet forwarding into an existing
internal-root setup is that the current "named" code doesn't allow the
two to co-exist; if you define a default forwarder, then your internal
root NS'es get happily overwritten by the root NS'es from the forwarder.
There is a patch being (hopefully) considered which will fix this, but
in the absence of that, you end up having to basically ditch your
internal roots and define (at least) the top-level zone of each of your
internal domains as type master, slave, forward or stub on each of the
nameservers which forward by default. This can become quite unmanageable
if you have a lot of internal domains.

Lastly, forwarding to the Internet by default is rather nasty for large
organizations because it means that virtually every misspelled TLD or
SLD issued from an internal client (if I had a nickel for every
"chrylser.com" query we get...) generates a query from your firewalls or
external DNS servers to the Internet roots. This effect is mitigated
somewhat by negative caching, and could be mitigated even further by
setting up dummy zones for some of the more common misspellings, but
it's wasteful nonetheless, and if your network service provider is the
type to charge you for each packet you send, I imagine it could get
somewhat costly as well.

My recommendation would be: try to limit the use of Internet forwarding
as much as possible; if it's not really a hard requirement, then try to
get out of doing it at all, or just limit it to a few workgroups or
business units. If you really *have* to implement Internet forwarding
enterprise-wide, and if you have a lot of internal domains, then pray
that ISC adopts the abovementioned patch so that you can still keep your
internal roots (and your sanity), otherwise you're doomed to waste
resources making unnecessary zone transfers or recursive queries for
your internal zones.

What do you mean by "negate domains", by the way? If you mean just
cancelling default forwarding for a particular name hierarchy, you can
already do that with the "forwarders { }" syntax.


- Kevin