44 How do I make DNS work with a firewall?
Description
This article is from the Firewalls FAQ, by Matt Curtin cmcurtin@interhack.net and Marcus J. Ranum mjr@nfr.com with numerous contributions by others.
44 How do I make DNS work with a firewall?
Some organizations want to hide DNS names from the outside. Many experts
don't think hiding DNS names is worthwhile, but if site/corporate policy
mandates hiding domain names, this is one approach that is known to work.
Another reason you may have to hide domain names is if you have a
non-standard addressing scheme on your internal network. In that case, you
have no choice but to hide those addresses. Don't fool yourself into
thinking that if your DNS names are hidden that it will slow an attacker
down much if they break into your firewall. Information about what is on
your network is too easily gleaned from the networking layer itself. If you
want an interesting demonstration of this, ping the subnet broadcast address
on your LAN and then do an ``arp -a.'' Note also that hiding names in the
DNS doesn't address the problem of host names ``leaking'' out in mail
headers, news articles, etc.
This approach is one of many, and is useful for organizations that wish to
hide their host names from the Internet. The success of this approach lies
on the fact that DNS clients on a machine don't have to talk to a DNS server
on that same machine. In other words, just because there's a DNS server on a
machine, there's nothing wrong with (and there are often advantages to)
redirecting that machine's DNS client activity to a DNS server on another
machine.
First, you set up a DNS server on the bastion host that the outside world
can talk to. You set this server up so that it claims to be authoritative
for your domains. In fact, all this server knows is what you want the
outside world to know; the names and addresses of your gateways, your
wildcard MX records, and so forth. This is the ``public'' server.
Then, you set up a DNS server on an internal machine. This server also
claims to be authoritative for your domains; unlike the public server, this
one is telling the truth. This is your ``normal'' nameserver, into which you
put all your ``normal'' DNS stuff. You also set this server up to forward
queries that it can't resolve to the public server (using a ``forwarders''
line in /etc/named.boot on a Unix machine, for example).
Finally, you set up all your DNS clients (the /etc/resolv.conf file on a
Unix box, for instance), including the ones on the machine with the public
server, to use the internal server. This is the key.
An internal client asking about an internal host asks the internal server,
and gets an answer; an internal client asking about an external host asks
the internal server, which asks the public server, which asks the Internet,
and the answer is relayed back. A client on the public server works just the
same way. An external client, however, asking about an internal host gets
back the ``restricted'' answer from the public server.
This approach assumes that there's a packet filtering firewall between these
two servers that will allow them to talk DNS to each other, but otherwise
restricts DNS between other hosts.
Another trick that's useful in this scheme is to employ wildcard PTR records
in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for
any of your non-public hosts to return something like
``unknown.YOUR.DOMAIN'' rather than an error. This satisfies anonymous FTP
sites like ftp.uu.net that insist on having a name for the machines they
talk to. This may fail when talking to sites that do a DNS cross-check in
which the host name is matched against its address and vice versa.
Continue to:
My Books
