Internal and External DNS

[Kevin Darcy]

Shannon Rush wrote:

> I would like to move my companies Internet DNS service in-house.  We have a
> registered domain with a /26 public IP block.  We currently use the class A
> network 10.x for our internal IP addressing, and have a firewall that does
> NAT for all the addresses that need to be seen from outside our intranet.  I
> need to find the most elegant way to set up my DNS servers for our public
> and private networks.  I would like to use the same names in both our
> private and public name space for the several machines that are publicly
> accessible from the Internet.  Can this be done, and if so how?
>
> Shannon Rush
> rushs at lexiconmarketing.com
> Network Administrator
> Lexicon

In order to be able to resolve the same names differently on the inside versus
the outside, the only solution I know is to actually have separate instances of
the zones inside versus outside. Not very elegant, I know, but that's life in
the firewalled-DNS biz. So you define one or more internally-accessible servers
to be masters for the internal versions of your zones (preferrably with some
slaves for redundancy) and you define some other machines to serve a "shadow",
externally-accessible version of the zones. The internal servers serve the
internal addresses for the servers, and the external servers serve the external
addresses.

Okay, so now that you have different versions of your zones running on the
inside and outside, how do you prevent an internal client getting the wrong
address? You need to make sure that all nameservers being used by internal
clients are able to resolve those names *without* getting any information from
an externally-accessible source. If you are using forwarding to resolve
Internet names, for instance, you need to make sure all of the client-serving
nameservers are masters or slaves for the zones that contain the servers in
question (so that all of the names will always be in cache and they won't
forward for them), or that they override the global forwarders with a different
set of zone-specific forwarders, i.e. consisting only of internal servers. In
this way, the clients never see the external addresses for your
externally-accessible servers.

Another thing I'd add is that if you have no requirement to resolve Internet
names from the inside, you may wish to consider running a "pure" internal-root
architecture, which requires a little more configuration work, but offers some
advantages in terms of robustness and performance. Also, when you run a pure
internal-root architecture, you need never worry about a client accidentally
getting an external address for one of your servers, since none of your
nameservers need know that any names even exist outside of your intranet. One
of the drawbacks of this provincialism, however, is that if you want to route
outbound mail using MX records, you might have to play some games with
wildcards and the like, otherwise the mail servers will simply declare that the
destinations are non-existent.

Lastly, there is the question of how to configure the firewall's resolver.
Typically, firewalls need visibility to the external namespace and at least
part of the internal namespace. If a local nameserver is configured on the
firewall with a proper Internet root hints file, it can resolve whatever it
needs in the external namespace, and, additionally, you can inform that
nameserver about the internal namespace by using some of the methods described
above, i.e. making it a slave to the internal zones, or having it forward to
internal servers for those zones. If you are planning to use your firewall as a
nameserver for the externally-accessible versions of your zones (because you
might not want all of that DNS traffic being NAT'ed to some internal server,
and you don't have a spare external machine to serve the zones), but you want
some degree of visibility to the internal namespace, you can run a separate,
"private" instance of named on an internal or a loopback interface for the
firewall's own name-resolution needs; you just need to do some extra
configuration so that the 2 nameserver instances will peacefully co-exist with
each other. Alternatively, you could have the firewall's resolver pointed to
some internal nameserver that has all of the information about internal zones
(as a master or slave) and a way to also resolve Internet names, e.g. by
sending queries back out through a firewall, using forwarding (or possibly
NAT?).

The main issue with the firewall's resolver, however, is what to do about the
zones that contain the names of the externally-accessible servers: you'll need
to make the decision of whether the firewall will see the internal or external
versions, and this is often driven largely by the requirements of your firewall
software. Just bear in mind that this is a zone-by-zone decision, not a
name-by-name decision (unless, of course, you are willing to configure and
maintain a separate zone for each of the names), so if you decide that the
firewall will only see external data for the foo.com zone, then *everything* in
zone foo.com will be resolved that way, and if a name only exists in the
internal version of foo.com, the firewall will be blind to it. If you have some
naming latitude, you can lessen the impact of this all-or-nothing choice
somewhat by shoving all of the externally-accessible stuff into a zone of its
own, e.g. extra.foo.com (you can then create aliases to those names, if you
wish, to make them more palatable to your users; just remember, though, that
you can't have an alias which is also the name of a zone).


- Kevin

P.S. The reason I refer to the internal-root architecture as "pure" is to
distinguish it from a "hybrid" global-forwarding/internal-root architecture,
which would be nice but currently doesn't work under BIND due to a territorial
dispute over root NS records :-|. So the choice right now is basically either
"resolve arbitrary Internet names" or "use internal roots": you can't have
both.