Jul 2008
In the previous DNS texts (1 and 2) an introduction to setting up a single DNS zone server and multiple zones was covered. In the third and final text; configuring primary/secondary servers, DDNS updates (and a glance at DHCPd), round robin DNS entries, plus various DNS options are examined.
Following is a recap of all the files used in the examples thus far:
/etc/named.conf
options {
directory "/var/named";
forward first;
forwarders {
172.20.10.10;
};
};
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";
};
/var/named/localhost
$TTL 86400
@ IN SOA @ root (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS @
/var/named/foo.net
$TTL 86400 ; 1 day
foo.net IN SOA foo.net. postmaster.foo.net. (
20071120 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
172800 ; expire (2 days)
43200 ; minimum (12 hours)
)
NS dns1.foo.net. ; the nameserver itself for this zone
dns1 IN A 172.30.0.10 ; the nameserver
webserv1 IN A 172.30.0.11 ; our coolio webserver
stor1 IN A 172.30.1.12 ; the big ole storage boxen
/var/named/172.30
172.30
$TTL 86400 ; 1 day
30.172.in-addr.arpa IN SOA foo.net. root.foo.net. (
20071120 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
172800 ; expire (2 days)
43200 ; minimum (12 hours)
)
NS dns1.foo.net.
10.0 IN PTR dns1.foo.net.
11.0 IN PTR webserv1.foo.net.
12.0 IN PTR stor1.foo.net.
/var/named/bar.net
$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
/var/named/172.23
$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.0 IN PTR dns.bar.net.
20.0 IN PTR files1.bar.net.
Although the nomenclature is not politically correct, the secondary DNS server is referred to as the slave DNS server which it will be referred to from this point on to minimize confusion. Adding a slave server is pretty simple:
named.conf file on the slave.named.conf modifications to the master
server using the allow-updates option.named.conf on the SlaveBy far the easiest method to configure the slave is to copy the
named.conf file from the master over then modify it.
All the slave needs is a few redefinitions of file (or db
file) types:
options {
directory "/var/named";
forward first;
forwarders {
172.20.10.10;
};
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost";
};
zone "172.30" {
type slave;
file "slaves/172.30";
masters {
172.30.0.10;
}
};
zone "foo.net" {
type slave;
file "slaves/foo.net";
masters {
172.30.0.10;
}
};
One entry was changed and one added, the file entry
now puts all of the zonefiles into /var/named/slaves/.
The entry is of the form slaves/filename because in
the options section the directory containing the files
is defined by directory "/var/named"; hence all
subsequent file entries are relative to /var/named.
The additional entry points to the master DNS server by IP
address.
Configuring the slave to be able to pull and update from the master server is slightly more involved:
allow-transfer option to
named.conf.Assuming the slave server is at address
172.30.0.20 the allow-transfer is added
to named.conf which lets the slave server
update zones, only non-local zones require the option:
...
zone "172.30" {
type master;
file "172.30";
allow-transfer {
172.30.0.20;
}
};
zone "foo.net" {
type master;
file "foo.net";
allow-transfer {
172.30.0.20;
}
};
...
Once the allow-transfer option is configured all
that is left is making sure the zones that can transfer are aware
of the secondary server by adding a valid entry for the host in
every zone then adding the NS - note that the networks
for these zones are disparate; the 172.30 zones are
the ones being transferred:
/var/named/foo.net
NS dns1.foo.net. ; the nameserver itself for this zone
NS dns2.foo.net. ; the nameserver itself for this zone
dns1 IN A 172.30.0.10 ; the nameserver
dns2 IN A 172.30.0.20 ; the nameserver
...
/var/named/172.30
NS dns1.foo.net.
NS dns2.foo.net.
...
10.0 IN PTR dns1.foo.net.
20.0 IN PTR dns2.foo.net.
...
The last steps are to restart the master and activate the
slave; RedHat is used in
the following however the actual init operation varies
by platform:
dns1> service named restart dns2> chkconfig named on dns2> service named start
It is very likely that a DNS server is either dual
homed or on a network where the administrator may not want
everyone to be able to query the server. There are several ways to
restrict who may make queries and where. Two particular methods are
the query and notify options. The options
do exactly what they sound like; one specifies who may query and
the other who should be notified if anyone at all. The arguments
can be networks, any, no or none. In the example below
query is allowed for the two networks being served
while notify is simply turned off:
options {
directory "/var/named";
forward first;
forwarders {
172.20.10.10;
};
};
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";
allow-transfer {
172.30.0.20;
}
allow-query {
172.30/16;
}
notify no;
};
zone "foo.net" {
type master;
file "foo.net";
allow-transfer {
172.30.0.20;
}
allow-query {
172.30/16;
}
notify no;
};
zone "172.23" {
type master;
file "172.23";
allow-query {
172.23/16;
}
notify no;
};
zone "bar.net" {
type master;
file "bar.net";
allow-query {
172.23/16;
}
notify no;
};
There are several other options for restricting access as well such as only allowing a particular interface or even IP address (or both) to reply to DNS queries.
Round robin entries can be used to load balance a service. The most common service to load balance is www. There are two ways to do so which result the same:
... www IN A 172.30.0.14 www IN A 172.30.0.15 www IN A 172.30.0.16 ...
or
...
www IN A 172.30.0.14
IN A 172.30.0.15
IN A 172.30.0.16
...
Note that mail or MX records have an additional
method; by using multiple real names and the same priorities a
level of load balancing can be achieved:
... IN MX 10 mail.bar.net. IN MX 10 mail1.bar.net. IN MX 10 mail2.bar.net. ... mail IN A 172.23.1.10 mail1 IN A 172.23.1.11 mail2 IN A 172.23.1.12 ...
The series covers enough of DNS to get a solid DNS server up and running. While setting up DNS initially seems daunting once it is rolled out, DNS ends up being similar to most UNIX network services - periodic config changes, updates and service restarts.