Bind 9 Configuration for Public DNS behind NAT

Marc.Thach at Marc.Thach at
Tue Oct 9 09:32:28 UTC 2001

You may well be better off putting the DNS server outside the NAT boundary.
A common mistake people seem to make is that they do not consider why they
are using NAT, when it is and isn't appropriate, where the boundary should
be, and what disadvantages result.  I have seen numerous queries to this
list about DNS and NAT but have never seen any of them correctly resolved
(they may have been, but none of them ever said).  I have never used the
Cisco PIX but I have successfully used their router NAT in the past.
A DNS server behind DNS NAT ALG can never be as functional as an un-NAT'd
DNS server.  NAT breaks the address space into multiple views, the DNS
model was never bulit to cope with this and a DNS ALG can never just
magically glue it together again.  However a NAT DNS ALG is essential for A
record resolution where dynamic NAT mappings are used.  It is also required
where hosts are attached to a number of networks across one or more NAT
boundaries (different per attached network) and the clients are atteched to
an unspecified number of the same networks.
In the simple scenario where an Internet server is statically mapped behind
a single NAT boundary, then a DNS ALG is not generally required.  It is not
even really necessary where that Internet server is multiply-connected
behind more than one NAT boundary.  IMO you are generally better off trying
to split the DNS into internal/external by another mechanism.
NS records don't require translation (only their associated A records), but
you need to check whether the PIX lets them through at all, it should
translate all A records for which there is a valid mapping and which are
from NAT'd DNS servers.  You cannot zone transfer through a DNS ALG.  I
can't help you with your network group 8v)
Marc TXK
The views expressed are personal and do not necessarily reflect those of
the organisation providing the mail address from which this message was

                    jwilliams at bluwa                                                                                
           (Jack           To:     comp-protocols-dns-bind at                      
                    Williams)              cc:                                                                     
                    Sent by:               Subject:     Bind 9 Configuration for Public DNS behind NAT             
                    ce at                                                                                     

We are taking over management of our public DNS and are planning to
put in on the DMZ behind a PIX firewall. We will end up with 4 servers
at two sites hosting our public IP addresses.The DMZ uses a private
address space 172.16.x.x with is statically natted out to a public ip.

In creating the zone files forward lookup zones for our domain
( and reverse lookup zones for the loopback and our public
address space. In the forward and reverse zones I used the public
addesses for the name servers. When I tried to test the configuration,
it failed, because the name servers had no reverse lookup zones for
the private addresses. I created reverse lookup zones for the private
network and changed the NS records to point to the private address.
Bind 9 will now start and resolve names.

I now need to move this configuration to the DMZ where it will be on a
NATted subnet and have the following questions:

1. Will I run into any issues with the name servers have a private
address? I know that the PIX will translate A records and PTR records,
but the cisco docs don't mention NS records. If someone connected to
the server and issued a query for the name server itself (
would they get the internal IP or the public ip?

2. Am I better off putting the server directly on the internet and
avoiding NAT. I would really like to have the firewall between me and
the Internet, but my network group wouldn't commit today on whether or
not they could get me a non-natted firewalled address.

Thanks for your help,

Jack Williams

More information about the bind-users mailing list