Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Adding a Slave DNS Server

The Internet would be an unpleasant place without slave servers. Slaves receive their data directly from a master DNS server, from a slave receiving data directly from a master, or maybe even from something more removed than that. Thus, you can control a large number of slaves by administering a single master.

The process of receiving that data is called a zone transfer. Zone transfers happen automatically when either of the following two events occurs:

NOTE

NOTIFY (the second event) works only with BIND 8 and higher servers and slaves.

The point is, with only one master to maintain, you can control a large number of slave DNS servers, making it practical to spread the work among numerous servers in different parts of the world.

Spreading the work is one advantage of slave DNS servers. A second advantage is that it's an easy way to create a second DNS server for each zone, enhancing reliability through redundancy while keeping only one point of administration. Note that although slave servers get their data from the master, they write it to disk, so they continue to provide DNS services even if the master goes down.

In this section you'll create a slave DNS server for the domain.cxm and 100.168.192 (reverse DNS) zones on host mydesk. Here's a synopsis of how it's done:

  1. On mydesk named.conf, add slave zones domain.cxm and 100.168.192. in-addr.arpa.
  2. Restart named on mydesk.
  3. On mainserv named.domain.cxm, add mydesk as a second nameserver.
  4. On mainserv named.192.168.100, add mydesk as a second nameserver.
  5. Restart named on mainserv.
  6. Test.

NOTE

If domain.cxm were a legitimate domain in the worldwide DNS system, the master and any slaves would need to be delegated authority from above before they would work as DNS servers. However, because domain.cxm is a bogus domain constructed for this example, it is not necessary in this case.

Adding Slave Zones to mydesk

Add the following zones to /etc/named.conf on server mydesk:

zone "100.168.192.in-addr.arpa" {
  type slave;
  file "slave.192.168.100";
  masters { 192.168.100.1;} ;
};

zone "domain.cxm" {
  type slave;
  file "slave.domain.cxm";
  masters { 192.168.100.1;} ;
};

On each one, the file statement names the file in which to write data obtained from the master and from which to answer queries. The masters { 192.168.100.1;} ; statement (and be sure to punctuate it exactly that way) tells named to acquire data from 192.168.100.1 whenever the refresh time is exceeded or whenever it's hit with a NOTIFY from 192.168.100.1, whichever comes first. The type slave statement tells named that this zone is allowed to do zone transfers to obtain the data from 192.168.100.1.

Notice that the files start with the word slave instead of named. This convention allows the administrator to refresh all slave zones with an rm slave.* command and a named restart command. Unlike the master zone data files, these slave zone data files are not maintained by humans and can be regenerated by the server. Contrast this with deleting a master's zone data file, which would be disastrous. Of course, if the master is down, deleting the slave files would be equally disastrous, so take care before you delete any slave zone data file.

Once the slave zones have been added, simply restart named with this command:


   # /etc/rc.d/init.d/named restart

The named daemon will create the slave zone data files and will in fact act as a slave DNS server in every respect except for receiving NOTIFY statements (the master doesn't yet know about this slave server).

So it's perfectly possible to set up a slave to a master without the master knowing it. Because of the extra traffic burden placed on the master, this is not proper DNS etiquette. The administrator of the master should be informed of all slaves.

The master can defend itself against unauthorized slaves by limiting the servers that can receive zone transfers. Just put one of the following statements in named.conf's zone section(s) or in the global section:

allow-transfer { 192.168.100.2; };   #only mydesk can be slave

or

allow-transfer { 192.168.100.2; 192.168.100.10};   #both

or

allow-transfer { 192.168.100/24; };   #only hosts on subnet

Verify the existence of files /var/named/slave.domain.cxm and /var/named/slave. 192.168.100. If they exist, verify that this list of commands quickly gives the expected output:

nslookup mainserv 192.168.100.2
nslookup mydesk 192.168.100.2
nslookup mainserv.domain.cxm 192.168.100.2
nslookup mydesk.domain.cxm 192.168.100.2
nslookup 192.168.100.1 192.168.100.2
nslookup 192.168.100.2 192.168.100.2

In the next section, you'll make the master aware of the slaves so it can send the NOTIFY statements upon modification and restart.

Adding Second Nameservers to mainserv

Add the following line below the IN NS statement in named.domain.cxm:

             IN    NS           mydesk

Before you save your work and exit, be sure to increment the serial number (the first number in the parenthesized SOA list).

Now add this line below the IN NS statement in named.192.168.100:

             IN      NS      192.168.100.2.

Remember that the address of mydesk.domain.cxm is 192.168.100.2. Once again, be sure to increment the serial number. The incremented serial number is what tells the slave it needs to do the zone transfer.

Finally, restart the mainserv DNS server with this command:


   # /etc/rc.d/init.d/named restart

The addition of the NS record enables NOTIFY statements to be sent to the DNS server on mydesk, causing that server to initiate a zone transfer. The new NS record also enables mydesk to be used as a backup nameserver.

To verify that the slave zones are working, do the following shell commands and make sure you get the expected output:

nslookup mainserv 192.168.100.2
nslookup mydesk 192.168.100.2
nslookup mainserv.domain.cxm 192.168.100.2
nslookup mydesk.domain.cxm 192.168.100.2
nslookup 192.168.100.1 192.168.100.2
nslookup 192.168.100.2 192.168.100.2

DNS slaves and their zone transfers, together with delegation, give DNS the power to serve millions of URLs.

Share ThisShare This

Informit Network