Feb 2008
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.
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.
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.
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
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.
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.
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
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.
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.
(based on last 2 months log reports)
