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