Setting up DNS in DMZ

[Kevin Darcy]

Tim Stanley wrote:

>So, if I understand this right, here's what I got:
>
>Public 205.xxx.xxx.xxx
>DMZ 192.168.1.xxx
>Private 192.168.2.xxx
>
>The dns is, for example, 192.168.1.1.
>
>So, I build a zone for my domain using addresses from the 205.xxx.xxx.xxx
>network in the DNS. I also have a reverse zone for the 205.xxx.xxx.xxx
>network on the DNS.
>
Right. Those would be for any "external" clients who need to connect to 
your resources externally, which might possibly include some of your DMZ 
clients, depending on how you are set up.

>Question I have, is, do I build a separate "zone" and reverse zone for the
>192.168.1.xxx network on the DNS? Is this what you are talking about using
>Split DNS for?
>
Yes. You'd set that up for your *internal* clients. In fact, you may as 
well go ahead and set up 168.192.in-addr.arpa, even if you're only using 
a part of the 192.168.*.* range, since there is no reason you'd want to 
send 192.168.*.* reverse queries out to the Internet. If 
168.192.in-addr.arpa gets too unwieldy, you can always delegate subzones 
later...

>Does it really matter what the host name of the DNS server is? That is, does
>it need to be a FQDN in my "registered" domain?
>
Depends on what exactly you mean by "host name". If you mean the 
so-called "node name" that the box knows itself by, then that doesn't 
have any direct relationship to DNS. If you mean the name by which it is 
reached by clients via DNS lookup, then obviously there is a requirement 
that the name resolve to the correct address(es).

                                                                         
                                                      - Kevin

>These are some of the questions I have. I've searched over the Internet for
>examples, but just haven't found them yet.
>
>Thanks!
>"jeff donovan" <jdonovan at beth.k12.pa.us> wrote in message
>news:c4u7r0$1sqh$1 at sf1.isc.org...
>  
>
>>On Apr 5, 2004, at 8:16 PM, Kevin Darcy wrote:
>>
>>    
>>
>>>Tim Stanley wrote:
>>>
>>>      
>>>
>>>>I'm looking for examples of a correct way to set up a dns in a DMZ -- 
>>>>a
>>>>hardware DMZ. Not setting up named on a system that has a firewall,
>>>>but
>>>>setting up named in the DMZ.
>>>>
>>>>Of course, on a firewall, there is the registered ip range, and 2
>>>>private
>>>>ranges. The dns is for the registered ip range, however, it is set in
>>>>one of
>>>>the private ranges. So, what is appropriate for configuring the dns?
>>>>
>>>>        
>>>>
>>>If your nameserver has an address in a private range, then you'll need
>>>to do some NAT'ting, of course, in order for other Internet nameservers
>>>to be able to communicate with it. All of the DNS data you serve to the
>>>Internet will also need to need to be public addresses, with NAT'ting
>>>being done as necessary between the HTTP/SMTP/whatever clients on the
>>>Internet and your servers. Some NATs are smart enough -- or *think*
>>>they
>>>are smart enough, but actually get it wrong -- to change
>>>private-to-public addresses in DNS response packets on the fly. But I
>>>wouldn't trust that technology. The more traditional approach is to
>>>implement "split DNS" with internal and external databases for your
>>>names -- in the "internal" database, the DMZ names would resolve to
>>>private addresses, and in the "external" database, the DMZ names would
>>>resolve to public addresses. If you use BIND 9, you could serve both
>>>the
>>>internal and external databases from the same nameserver instance, if
>>>you wanted, differentiating the answers by client source address via
>>>the
>>>"view" feature.
>>>      
>>>
>>Greetings
>>Kevin gave me the same advise about 2 years ago, and it has worked
>>great.
>>Only hickup is managing two databases. After a while it gets pretty fat.
>>-----------------------------------
>>jeff donovan
>>basd network operations
>>(610) 807 5571 x4
>>AIM  xtdonovan
>>fwd# 248217
>>
>>
>>    
>>
>
>
>
>
>
>  
>