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.
systhread's
