we've spent a great deal of time configuring the master server. Now that it's up and running, let's turn our attention to the slave name server(s). In a network, we can only have a single master server, but we can have multiple slaves.

The larger ISP's will, on the whole, have many slaves to ease the load across the network, which could potentially be a bottleneck.

As mentioned previously, the slaves are in no way less important than the masters, and slaves in their own right can be masters of a different zone. In this way, one master can be the slave of a master from another zone.

The primary difference between the master and the slave however is the fact that slaves get their information from masters by the process of zone transfers. we'll see zone transfers occur as soon as our slave is going.

Slaves are really easy to configure, since they don't need any zone files. Well, not quite. They do require zone files for the localhost and 127.0.0 zones. Since these files are standard across all name servers, and since it makes little sense to transfer this zone between one name server and the next, they should be present on the slave. Again, they will probably reside in /var/named (on Debian they are in /etc/bind/).

We will also require an /etc/named.conf (on Debian again that's in /etc/bind/named.conf).

For the other zones, the slave will transfer them from the master automatically.

The primary differences in the layout of the named.conf files is as follows:

Slave name servers do not have:

type master;
                

in their zone entries but rather

type slave;
                

Slave servers specify a slightly different name for the zone files they draw from the master, although this is not a prerequisite.

file "bak.172.16.43.zone";
                

or

file "zoo.org.za.backup.zone";
                

A masters keyword indicate who the master server is for this zone:

masters { 157.236.144.1; };
                

So a zone entry for the zoo.org.za zone would look as follows:

zone "zoo.org.za" {
	type slave;
	file "zoo.org.za.backup.zone";
	master { 157.236.144.1; };
}
                

Now we're ready to start our slave server. We start it again just like we started the master server. If you start it in the foreground as before:

named -g -u named -c /etc/named.conf
                

You should see the IXFR (inter-zone transfer) taking place:

Feb 24 14:27:59.117 \
            zone zoo.org.za/IN: transfered 
            serial 2004022301
Feb 24 14:27:59.117 \
            transfer of 'zoo.org.za/IN' from 
            192.168.10.144#53: end of transfer
Feb 24 14:27:59.118 \
            zone zoo.org.za/IN: sending notifies 
            (serial 2004022301)
Feb 24 14:27:59.631 \
            zone 10.168.192.in-addr.arpa/IN: 
            transfered serial 2004022301
Feb 24 14:27:59.632 \
            transfer of '10.168.192.in-addr.arpa/IN' 
            from 192.168.10.144#53: end of transfer
Feb 24 14:27:59.634 \
            zone 144.236.157.in-addr.arpa/IN: transfered 
            serial 2004022301
Feb 24 14:27:59.634 \
            transfer of '144.236.157.in-addr.arpa/IN' 
            from 192.168.10.144#53: end of transfer
Feb 24 14:27:59.634 \
            zone 10.168.192.in-addr.arpa/IN: sending notifies 
            (serial 2004022301)
Feb 24 14:27:59.635 zone \
            144.236.157.in-addr.arpa/IN: sending notifies 
            (serial 2004022301)
Feb 24 14:27:59.639 \
            zone 43.16.172.in-addr.arpa/IN: transfered 
            serial 2004022301
Feb 24 14:27:59.639 \
            transfer of '43.16.172.in-addr.arpa/IN' 
            from 192.168.10.144#53: end of transfer
Feb 24 14:27:59.639 \
            zone 43.16.172.in-addr.arpa/IN: sending notifies 
            (serial 2004022301)
                

Once this is done, you can change your nameserver directive in the resolv.conf file and test it. Alternately, you can issue the command:

dig @my-slave-DNS-name-server +search ikki
                

which should be able to answer the query without any problems.

Now that we're dealing with slave servers, let's return to consider the numbers in the SOA record.

zoo.org.za.	IN	SOA	baloo.zoo.org.za. mowgli.zoo.org.za. (
                        2004022401; Serial
                        3h; Refresh after 3 hours
                        1h; Retry after 1 hour
                        1w; Expire after 1 week
                        1h; Negative caching TTL of 1 day
                        )
                

Serial is a number indicating the 'revision' of the zone file. Whenever a change is made to the zone file, this serial number should be updated. It is only by updating the serial number, that slave servers will themselves be updated. Each "refresh" time, the slaves will contact the master server, and check whether the serial number has changed. If so, the slave will do an interzone transfer of the masters zone files.

The DNS administrator has the responsibility of updating the serial number for each change made to the zone file. Any number may be used, being incremented in sequence for every change.

It is common practice however to use a serial number in the form of:

YYYYMMDD##
                

where

YYYY --- is the year, including the centuary,
MM   --- is the month,
DD   --- is the day the zone file is updated and
##   --- is the nth updating of the zone file that day.
                

	Note
	do not be tempted to format the date in any other style e.g. DDMMYYYY, since this will not produce sequential numbers, and your slaves will give unpredictable results

The slaves cannot keep answering DNS requests indefinitely. In fact, if a slave has not received an update from the master for more than a week, the slave will not answer any further questions.

So, why do the master zone files contain the expiry time?

Since slaves obtain their zone files from the master, this in effect tells the slaves how long to answer queries in the absence of the master zone transfers.

A point worth noting here is that the slaves store the zone files locally just in case the master is not available when the slave starts up. In this case, the slave will read the zone files locally rather than forcing a zone transfer.

More on this later when we discuss rndc the section called “Rndc”, the DNS name server control software.

This it the time that the slaves will wait before retrying to get the zone files from the master if the master was down the first time they tried. In fact the retry time is the time between one retry and the next retry.

This is the time that the NEGATIVE cached entries will remain in the slave servers.

(See the explanation earlierthe section called “The $TTL directive” for other TTL directives.)

On the Internet, one of the most important jobs is that of sending email.

The only problem is that one mail server needing to send email to another, needs to know what the mail servers IP address is. No problem you say, DNS will be able to solve that.

The problem is that a domain might have 10 hosts in the DNS. Perhaps more. Given this, which host is the SMTP server?

Now the sending host could test each server in the domain, to determine which of the 10 hosts is SMTP capable, but apart from the inordinate amount of time this would take, and the unnecessary network traffic it would generate, this is certainly not a solution the DNS designers would want to consider.

To solve this problem, there is the MX or mail exchanger record (just another type of resource record actually).

Generally a domain will have at least one MX record, but may in fact have any number to solve issues of redundancy. The MX record specifies the host(s) responsible for transfer of email for that domain. So, when a sending mail server wishes to send email to a user at a domain, it would request the MX record for the receiving domain, and thus be able to initiate a SMTP connection to the host.

Figure 2.8 illustrates the process of two SMTP servers exchanging email.

Figure 2.8. SMTP Process

humphrey@zoo.org.za (humphrey is a user on the host dorey) wishes to send an email to pooh@hundred-acre-wood.org.za

Since a domain can have more than a single MX record, each MX record will have a 'preference' value. This solves problems of routing loops, and also allows a single server to bear the brunt of the mail load. Should this server fail, alternate servers (admittedly with higher preference values) will take over the responsibility.

The numbers are simply an ordering scheme. When mail is delivered, the MX record with the lowest preference value will be the place where mail is delivered. Should the mailer fail to deliver the message to this MTA, then the next highest preference mail server will be selected.

Finally, two or more MX record can contain the same preference value. In this case, which mail server receives the mail is irrelevant.

rndc is a utility that allows us to manipulate our BIND server.

It is useful in that it allows us to stop and restart the server, force refreshes of the zone files or slave zone transfers, flush server caches, etc.

The most obvious thing you want to do with rndc is to refresh the zone files on the slave.

To test this, you will need to make a change to the master zone files. In fact, simply changing the serial number in the zone file is enough.

Once you've changes the serial number, issue the rndc command:

rndc reload 144.236.157.in-addr.arpa
                

Then look at your log file (usually /var/log/messages or /var/log/syslog), and you should see the altered zone file is reloaded. You should be able to tell using the serial number.

Feb 24 14:51:34 \
            baloo named[559]: zone \
            144.236.157.in-addr.arpa/IN:
	loaded serial 2004022302
Feb 24 14:51:34 \
            baloo named[559]: zone \
            144.236.157.in-addr.arpa/IN: 
	sending notifies (serial 2004022302)
                

Now, on the slave, issue the command:

rndc refresh 144.236.157.in-addr.arpa
                

and the zone files will be transferred to the slave.

Other rndc commands will produce statistics on the servers, reconfigure the name servers and more.

Sometimes you may not wish to set up a full name server.

Typically, users that are on the wrong end on a dial-up Internet connection (the slow end), might wish to configure a caching only name server. In this way, each time a query is done to the DNS server, it will be cached locally, speeding up future lookups to the same address.

Caching only name servers don't have all the advanced features we've been talking about in this module - they are only able to cache and answer queries that they already know about.

Configuring a caching only name server is also a whole lot easier to set up and administer than it's older cousin a master/slave name server.

In order to configure a caching only server, one needs to configure the /etc/named.conf file.

Instead of the zone entries, include the following options:

forwarders { 192.168.10.144; 196.14.187.146; };
forward  first;
                

This will ensure that all queries are forwarded to the name servers listed in the forwarders directive, while the "forward first" will first try to forward the query before trying to find the answer itself. that's it.

Now start the name server and begin building a cache of all the sites visited.

I have deliberately left out some sections in this module - those being DNS security, round robin DNS, and configuration of sub-domains. I hope to add these chapters in future releases of this course. If this specifically interests you, feel free to get the excellent DNS and BIND book referred to in resources below.