In a recent project requiring a firewall, my team decided on the
split DNS approach. We have a wildcard and single MX on the outside
and a full database on the inside, with "forwarder" interaction
between the two. All resolvers (firewall and backside hosts) point
to the inside DNS server.
Philosophical:
Our main goal was to give people flexibility to enforce
different levels of paranoia and security policies, while
providing a common implementation across numerous sites.
Even though we told sites that they should not name systems
with any sensitive or revealing words, some people just like to do
that. We explained all the ways host names show up in headers
even if you hide the names via DNS, but there was a "feeling"
that removing them from the external view of the DNS database
would be more comfortable. Here was an example of no good
technical reason, but a level of intangible comfort.
Technical:
We wanted to allow the site behind the firewall the freedom
to deliver email using DNS. That is, we did not want to limit
their choice of resolution method. Some sites have kept all
mail on a single server (ignoring MX records), while others
have used non-SMTP to distribute email behind the firewall.
Others actually use the inside set of MX records to deliver.
This was exactly the range of choices we wanted to offer.
For debugging (connectivity to other sites), you want to have
full name resolution available to you. This may not have to be
from a backside host and may not be needed by normal users, but
for sysadmins, it's a necessity (IMHO). You can call this
philosophical or "soft" technical if you wish.
Thoughts about *not* using the split DNS:
If your backside hosts did not care to use DNS at all, you
probably could get away with an extremely simple DNS database
and server on the firewall. All resolvers would point to the
firewall. Of course, you'd have to create some equivalent to
a host table for backside hosts to use to contact each other.
Walt
References:
|
|
