Feb 2008

DNS 2: Forwarding & Multiple Zones

In the first part of the DNS texts a brief overview of how DNS works and a very simple DNS server setup was addressed. In this text; forwarding DNS requests outside of the local zones, q quick look at the options section of named.conf and configuring multiple zones (both multple domains and network addresses) are examined.

DNS Forwarding

The concept of DNS forwarding is simple:

If the local zone(s) cannot answer the query, forward the request to a valid server to try to resolve the query.

For example; in the following configuration the local zone is foo.net, however, it is for a local domain in an office building. The corporate network has other DNS zones which the system administrator of foo.net is not responsible for.

Resolver Path

client.foo.net -> dns1.foo.net

Yes I know what IP address that name resolves to...

client.foo.net <- dns1.foo.net

I do not know what IP address that name resolves to; but I know who to ask...

client.foo.net -> dns1.foo.net -> dns.corp.com
client.foo.net <- dns.corp.com

Note that the request is forwarded to the other DNS server, however, the reply does not travel back through the DNS server that forwarded the request. The implication is the client must have full network connectivity to the server the request was forwarded to in addition to knowing what domain(s) the server can resolve addresses for.

Configuring Forwarding

Setting up forwarding does require changes to named.conf and /etc/resolv.conf. Using the previous example from above and the first text along with having two servers to forward to in corp.com with an addresse of 172.20.10.10:

options {
        forward first;
        forwarders {
                172.20.10.10;
        };
};

The /etc/resolv.conf on client systems then must be changed to reflect the proper order:

search foo.net corp.com
nameserver 172.30.0.10

The client must be aware of at least what domain the forwarder can take care of; in certain configurations (server dependent) the client will not need to know all of the domains - just the primary one that the forwarder is managing. With forwarding configured; a query request now will look like:

    client.foo.net makes a request
        ask dns1.foo.net 
        dns1.foo.net knows the address?
                yes - send the information to client.foo.net
                no - forward the request to 172.20.10.10 
                         172.20.10.10 sends the information to client.foo.net

Options

The options record is used to set global options for the DNS server. The example only uses the forward and forwarders options, however, other options can be specified as well. A good example for options is entering the full path to file locations can be tedious (especially on larger servers where there can be several hundred records); instead the directory option can point to where the files are kept:

options {
        directory "/var/named";
        forward first;
        forwarders {
                172.20.10.10;
        };
};

The directory entry enables the system administrator to be able to use relative paths instead of absolute paths, it also makes moving the files a trivial exercise.

The Pro DNS and Bind book has a great section online which deals with option statements. In later texts some of these options will be examined in further detail.

Multiple Zones

More often than not within a single organization more than one domain is used for a variety of reasons. Setting up multiple domains for a small number of domains is the same as setting up a single domain; just add the appropiate records in named.conf and db files. Setting up a large number of domains, however, can be daunting and requires thinking about a strategy to simplify administration. One way to think of multiple zones is hosting multiple domains on one server, conceptually it is the same thing from an address resolution perspective.

The Easiest Example: Two Domains

Retaining the foo.net and forwarder example information, in the new example a new domain is being added to the existing DNS server; it is also on a different network. For simplicity the number of hosts will be kept low:

dns.bar.net    172.23.0.10   # DNS server for bar domain
files1.bar.net 172.23.0.20   # File server for bar domain
named.conf Records
zone "172.23" {
        type master;
        file "172.23";
};

zone "bar.net" {
        type master;
        file "bar.net";
};

Are the new records, now all together the named.conf file looks like:

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost";
};

zone "172.30" {
        type master;
        file "172.30";
};

zone "foo.net" {
        type master;
        file "foo.net";
};

zone "172.23" {
        type master;
        file "172.23";
};

zone "bar.net" {
        type master;
        file "bar.net";
};
bar.net Forward Lookup File
$TTL 86400  ; 1 day
bar.net         IN SOA  bar.net. postmaster.bar.net. (
                20071120   ; serial
                3600       ; refresh (1 hour)
                300        ; retry (5 minutes)
                172800     ; expire (2 days)
                43200      ; minimum (12 hours)
                )

            NS  dns.bar.net. ; the nameserver itself for this zone

dns        IN A   172.23.0.10 ; the nameserver
files1     IN A   172.23.0.20 ; file server
172.23 Reverse Lookup File
$TTL 86400  ; 1 day
30.172.in-addr.arpa IN SOA  bar.net. root.bar.net. (
                20071120   ; serial
                3600       ; refresh (1 hour)
                300        ; retry (5 minutes)
                172800     ; expire (2 days)
                43200      ; minimum (12 hours)
                )
            NS  dns1.30.172.in-addr.arpa.

10          IN PTR dns.bar.net.
20          IN PTR files1.bar.net.

After restarting the named process the changes will take effect. The named directory will now have two additional files:

$ ls /var/named
 172,23   bar.net    localhost
 172.30   foo.net   named.root

Thoughts

Setting domains side by side for organizational purposes may work, and when doing generalized DNS hosting versus building out a logical structure there is no choice in the matter. When working in an organization of some sort it might be wiser to think more in terms of levels than groups. Example what if the users of the bar.net domain are actually a sub-group within the same area? It might make more sense to setup a domain called bar.foo.net and possibly another server which forwards to the DNS server managing foo.net.

Another item to keep in mind when dealing with multiple domain hosting is management. Building out tables for up to a couple hundred systems might not be too much work for some people but in the long run the work might start to become an issue. There are many ways to deal with the problem of record management (and many tools available for that very problem). When going into a large installation that is using a lot of static addresses it is a good idea to think about either obtaining or creating tools to help manage DNS tables.

A good example of helper programs is the hosts2named script found on HP-UX systems, using a set of options an entire host file can easily be converted into a fully functional DNS server. The catch with hosts2named is the network address must be the same (unless you don't mind missing reverse records) and all statically assigned addresses have to be in the /etc/hosts file. If employed a certain way, that is to say all hosts are always kept in /etc/hosts on the DNS server itself, an adminsitrator may never even have to edit the DNS files.

Summary

Setting up DNS can be daunting or relatively easy; it often requires a slow methodical start. Not unlike most processes on Unix: once it is initially up and running the hard part is over (most - not all :-). Next time a look at configuring and using primary/secondary DNS, DNS debugging, more about options and DDNS updates.

prev - next