[vox-tech] Setting up DNS with BIND

[Jeff Newmiller]

On Tue, 7 Oct 2003, Nicole TWN wrote:

> Hi gang
> 
> I could use some help filling in the gaps in my knowlege of DNS servers; 
> time spent on Google has only confused me.  Here's my understanding of how 
> BIND works:
> 1. Looks in /etc/named.conf to find out whether it's a master or a slave, 
> and, if it's a master, where its zone file is;
> 2. Looks at its zone file, where it finds a bunch of 'A' or 'PTR' records 
> like "192.168.1.42    A     one.example.com."  This is also called the 
> 'forward' DNS file.
> 
> Now, where does the reverse DNS file fit in?  I've come across references 
> to such a thing--apparently they're full of records like 
> "42.1.168.192.in-addr.arpa.  A   one.example.com"  I think I'm supposed to 

I suggest not mapping ".com" domains to private networks.  I prefer
".localnet" as a private TLD to avoid naming confusion.  The root servers
are supposed to be responsible for .com, and they certainly know nothing
about your private network or its dns server.  While you can get away with
this by using a private name server, debugging the confusion can be
frustrating if you add an internal host without configuring it to refer to
your nameserver, particularly if the name you use happens to be one that
the root server has in its database.

Also, A records point to IP addresses... one.example.com is not an ip
address.

> add a corresponding reverse record whenever I add a forward record (and 
> before rehupping named), but what's the reverse file usually called and 
> where does it live?

Your questions seem to be specifying particular filenames, which probably
vary by distro and/or version of BIND, not to mention the fact that there
are alternatives to BIND.

The concept is that as the owner of a /24 or larger network you should
manage (or delegate management of) a special domain for that network
within the in-addr.arpa domain. You conceivably could then own zero or
more "normal" domains that you map to those ip addresses, but you can only
reverse map to one hostname per ip address.

If you "own" a smaller network, you need your ISP to handle the reverse
dns for you, though they may charge separately for that, preferring
instead to setup generic "public names" (based on the ip numbers
themselves) for "your" ip addresses.  If you are managing a domain on a
private ("NATed") network, be sure you prevent your private dns server
from responding to public requests.

I am no expert on BIND (some of its idiosyncracies have probably been
corrected in versions more recent than my reference materials[1]), but
here is the general idea:  a possible configuration is to have an
/etc/named.boot file that identifies the zohe files that cover your
domains (example.com and 1.168.192.in-addr.arpa):

   directory /var/domain
   ...
   primary  example.localnet           example.fwd
   primary  example2.localnet          example2.fwd
   primary  1.168.192.IN-ADDR-ARPA     mynet.rev
   ...

I put two forward entries here to emphasize that mapping domains to
networks is arbitrary... the important thing is the ip addresses they
forward to.  Reverse mapping is performed in the special network-specific
zone file, which is just another zone file. Capitalization is not
significant, but is traditional for the reverse lookup domain.

(In general, your authority to setup any these zone files varies.  If they
are public, normal domain delegation is managed through domain registrars.  
You tell them your dns server address, and they arrange to delegate
lookups to your name server. Reverse lookup domains are assigned along
with your range of public network addresses (from your ISP), who is often
not your domain registrar.  You tell them what nameserver you will use
with the network, and they delegate dns queries to your server.  If you
are on a private network, you have authority to do whatever you want, but
making your configuration use names and network addresses that don't
duplicate public network information makes interfacing with the Internet
much easier and less likely to adversely affect Internet servers and
users.)

With the above example, the answer to your question would be
"/var/domain/mynet.rev", which should contain an SOA record, NS records,
and PTR records for each reverse mapping:

   @   IN  SOA  ns.example.localnet. (
                 ... )
       IN  NS   ns.example.localnet.
   ...
   42  IN  PTR  one.example.localnet.
   ...

The SOA record specifies the nameservers that are authoritative for this
domain name.  The "@" represents 1.168.192.IN-ADDR.ARPA. because of the
fact that this file was referenced as the primary zone file in the boot
file.  As always, be VERY careful to end complete dns names with a period
in zone files if you don't want the @ tacked on.  The 42 in the PTR record
doesn't have a period, so it really represents 42.1.168.192.IN-ADDR.ARPA.

Understanding how private lookups work as opposed to public lookups may be
helpful when setting a private nameserver up. When your internal host
two.example.localnet asks for a reverse lookup of 192.168.1.42, it sends a
request for a PTR record for 42.1.168.192.IN-ADDR.ARPA to the nameserver
it is configured to ask.  As long as your nameserver ns.example.localnet
gets this before some other nameserver does, your nameserver will
recognize that it is authoritative for 1.168.192.IN-ADDR.ARPA, and provide
a response.  If two.example.localnet is configured to go straight to the
root servers (which it might do if it is an embedded device trying to
avoid lying nameservers for security reasons, or if you just didn't pay
attention during client setup), then the request will get a response
indicating that there is no matching record, and the reverse lookup will
fail, and the request will have wasted the root server' time (plenty of
that without misconfiguration adding to the problem).

I use dnscache/tinydns for my private network, which is a bit more terse,
but which automatically handles forward and reverse names in one place in
the configuration.  (If you decide to look into tinydns, note that unlike
BIND, tinydns has no option to forward requests when it is not
authoritative... instead, dnscache is expected to receive all requests and
forward requests locally or to the root servers as appropriate, so you
would likely want both.)

I hope that fills in some of the holes you wanted filled.  It certainly
doesn't address the specific filenames you wanted, but perhaps the
background will make finding them easier.

P.S. APNIC has an interesting discussion of reverse lookup
configuration. [2]  Also, the comp.protocols.tcp-ip.domains FAQ is
useful. [3]

[1] Unix System Administrator's Handbook, 2nd ed., by Nemeth, et. al.
[2] http://www.apnic.net/db/revdel.html
[3] http://www.faqs.org/faqs/internet/tcp-ip/domains-faq/part2/

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------