Implementing BIND on Mac OS X
Pages: 1, 2

Reverse Lookup Zones

Reverse lookup zones contain data for reverse DNS queries. A reverse query is used to resolve an address to a hostname.

As far as structure goes, a reverse lookup zone is the same as a forward lookup zone:

;
; /var/named/db.192.168.1 - Zone file for 192.168.1 network
;
$TTL 86400  ; 1 day
1.168.192.in-addr.arpa  IN  SOA ns.example.com. root.example.com. (
                            2003040101      ; Serial
                            10800           ; Refresh after 3 hours
                            3600            ; Retry after 1 hour
                            604800          ; Expire after 1 week
                            86400 )         ; Minimum TTL of 1 day

; name servers
1.168.192.in-addr.arpa  IN  NS  ns1.example.com.
1.168.192.in-addr.arpa  IN  NS  ns2.example.com.

; address to host mappings
1                       IN  PTR gateway.example.com.
2                       IN  PTR ns1.example.com.
3                       IN  PTR ns2.example.com.
5                       IN  PTR www.example.com.

You might notice that the main difference is in the use of PTR records instead of A records. PTR records are the most used record in a reverse lookup zone. The first field of a PTR record contains the last octet of the host's IP address. So, in the case of 192.168.1.1, it would be just 1. The value of the record is the fully qualified domain name of the host in question (for example, gateway.example.com.). Remember those trailing periods in fully qualified domain names!

The other portion that is different is the name of the zone. Reverse lookup zones are named by inverting the network address and adding ".in-addr.arpa" to it. For example, for a host with an IP address of 192.168.1.5, its network would be 192.168.1 (well, assuming you're using a /24 subnet mask). The reverse of the network would be 1.168.192. Slap on the ".in-addr.arpa" and you get the "1.168.192.in-addr.arpa" found in the zone above. Conversely, the filename for this zone would be db.192.168.1.

To load a reverse lookup zone, place the entry below in your named.conf file. The fields used are the same as those for a forward lookup zone.

zone "1.168.192.in-addr.arpa" in
{
    type    master;
    file    "db.192.168.1";
};

Zone Notation Shorthand

There are a few different shortcuts you can take when creating zone files. One allows you to use an @ symbol in place of $ORIGIN. The $ORIGIN for a zone file is specified in the named.conf configuration file in the zone field. In the reverse lookup example above, the $ORIGIN would be "1.168.192.in-addr.arpa". A revised version of the SOA and NS records for our reverse zone that uses @ notation would be:

@                   IN  SOA ns.example.com. root.example.com. (
                        2003040101      ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day
                                
; name servers
@                   IN  NS  ns1.example.com.
@                   IN  NS  ns2.example.com.

Note that if a different $ORIGIN is declared within the zone file then it will be used instead. A similar shortcut is that if you do not declare a new name for a record, named will substitute the last one used. For example, the zone above and the zone below both do the same thing:

@                   IN  SOA ns.example.com. root.example.com. (
                        2003040101      ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day
                                
; name servers
                    IN  NS  ns1.example.com.
                    IN  NS  ns2.example.com.

Notice that there is no indication of which host the NS records are for. Instead, it is assumed that the records are for the last entry used, which in this case is the @ record. These shortcuts should save you some time when creating zone files. By using them, you can also create generic zone files that will work with more than one lookup. A good use for this would be if you're running a web hosting service and have several zones that contain the exact same data. Create a single zone file that contains @ notation and then use it multiple times in your named.conf file.

The last shortcut I'll discuss is the use of non fully qualified domain names in zone files. In the example.com zone above, the www record is declared as:

www.example.com.    IN  A   192.168.1.5

If I were to specify just the host portion of this address, named will append the $ORIGIN to the end of the entry. This is the reason that you must be sure to put a trailing period on fully qualified domain names. The entry above and the entry below have the same result:

www                 IN  A   192.168.1.5

The named Configuration File

Using the blocks of data at the end of the various zone types above, you can create the majority of your named.conf configuration file with ease. The only remaining section is the options section declared at the top of the configuration file. The options section is used to specify parameters which affect named as a whole. Below is the example named.conf file, followed by explanations of the various sections:

//
// /etc/named.conf - Configuration file for named DNS server
//

// General Parameters
options
{
    directory "/var/named";
    
    forward first;
    forwarders
    {
        63.240.76.19;
        204.127.198.19;
    };
    
    allow-transfer
    {
        none;
    };
};


// Hint Zone
zone "." in
{
    type    hint;
    file    "named.ca";
};


// Domains (forward)
zone "example.com" in
{
    type    master;
    file    "db.example.com";
};


// Networks (reverse)
zone "0.0.127.in-addr.arpa" in
{
    type    master;
    file    "db.127.0.0";
};

zone "1.168.192.in-addr.arpa" in
{
    type    master;
    file    "db.192.168.1";
};

General Parameters

The options specified above work as follows: The directory declaration is used to determine where all of your zone files and other named configuration data is kept (this does not necessarily mean named.conf). The forward first and forwarders declarations tell named to forward all queries to the DNS servers listed before attempting to resolve the query on its own. Using query forwarding allows you to speed up your resolution process (it is usually quicker to query your ISP's server instead of the root servers). The allow-transfer section prevents unauthorized users from downloading entire copies of your zones. This is a security precaution that is similar to limiting someone to using directory assistance for telephone number lookups instead of giving them a phone book. The end user can only query for specific records instead of having access to the entire directory.

Domains and Networks

These sections contain the declarations for the zones above. Notice that in the Networks section there is a declaration for 0.0.127.in-addr.arpa. This zone represents the reverse lookup information for your machine's loopback address. Below is the zone's contents:

$TTL    86400
@       IN      SOA     localhost. root.localhost.  (
                                      1997022700 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      localhost.

1       IN      PTR     localhost.

Slave Servers and Zone Transfers

The final portion of the named.conf file that I'm going to cover is the configuration of slave servers. The DNS standards recommend that at least two name servers (on separate systems, networks, etc.) should be authoritative for your domain. While it is entirely possible to maintain two separate copies of a zone's data on two separate servers by hand, most administrators will instead choose to make one of the servers a master and the other a slave.

Slave servers use zone transfers to acquire their zone data from master servers. On the master server, you must allow your slave server to request whole zones. One the slave server, you must configure the slave to request zones from the master. Below are the two entries necessary; the first for the master, second for slave:

// master zone
zone "example.com" in
{
    type    master;
    file    "db.example.com";
    allow-transfer
    {
        192.168.1.3;
    };
};

// slave zone
zone "example.com" in
{
    type    slave;
    file    "db.example.com";
    masters
    {
        192.168.1.1;
    };
};

Final Thoughts

While I haven't touched upon every portion of BIND, this article provides enough information to get you started with a basic DNS setup. For further reading, I highly recommend DNS and BIND by Paul Albitz and Cricket Liu. It's a must read for anyone who will be working with BIND on a regular basis.

Jason Deraleau works as a systems administrator by day, IT consultant and technical writer by night, and is the coauthor of the upcoming Running Mac OS X Tiger.

---

Return to the Mac DevCenter.