|
|
If you have made the commitment to hosting master DNS services locally, it is likely that you need to run a slave server as well. All but the most frugal administrators who are serious about staying online run a slave name server on a separate LAN, or at least on a separate machine from the master server. The slave server comes into play when your master server is bogged down, or completely offline. Clients will be directed by other name servers to the DNS server with the lowest latency time. This functions as a sort of natural load balancer.
| Caution |
You should run slave name servers on separate physical boxes, if not on separate networks altogether. System administrators who have a "damn the torpedoes" philosophy, or who are simply inexperienced, sometimes point the registrar toward two IP addresses on the same server. In many cases, this server also provides web and e-mail services. This "single-point-of-failure" design is unwise, but popular nonetheless among those who need a shoestring budget solution on a single machine. A better alternative involves hosting master DNS service locally and using one of your upstream provider's DNS servers as the slave server, or reverse, if your provider offers simple web tools to manage your domains and IPs. |
The slave name server pulls its records from the master server on a regular basis. This basis is defined by the Start Of Authority (SOA) block in the master zone file as shown previously. In this section, we show you how to configure a slave name server and make sure that it synchronizes cleanly with the master name server for your domain.
Slave name servers use the same file layouts as does the master name servers: /etc/named.conf and the zone files in /var/named/. Only the path of the zone files is defined in a slave's /etc/named. conf file. The zone files themselves are created by the named service itself when it pulls the zone information from the master name server.
Thus, a zone entry in a slave server's /etc/named.conf file will look much like an entry in the master server's /etc/named.conf. In this example, the slave server is configured to pull information from a master server at 10.1.1.1 and save start-up zone data to its disk:
zone "example.com" IN {
type slave;
file "example.com.zone";
masters [ 10.1.1.1; };
};
In order to ensure that the master name server knows that there are slave name servers, and that it will notify all slave name servers of zone changes, you must edit the master server's /etc/named.conf file to include the notify yes directive. You should also enable the allow-transfer directive, which permits the specified IP addresses (either slave name servers or internal administrative workstations) to pull down zone transfers. The following sample block shows slave transfer and notification enabled:
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
notify yes;
allow-transfer { 192.168.128.3; };
};
If any zone changes are made on the master name server, a NOTIFY signal is sent to all slave name servers. The slave name servers will refresh their caches if the serial number on the master server's zone file is higher than the serial number on the file in the slave name server cache. This is why you must be sure to increment the serial number each time you change the master server's zone file.
When you make a change to the zone file and increment the serial number, you must reload the named service. Once the service is reloaded, you will see entries like these in the system log stored at /var/log/messages:
# tail /var/log/messages
...
Jan 18 19:45:13 localhost named[5622]: loading configuration from
'/etc/named.conf'
Jan 18 19:45:13 localhost named[5622]: no IPv6 interfaces found
Jan 18 19:45:13 localhost named[5622]: zone example.com/IN: loaded
serial 2004011809
Jan 18 19:45:13 localhost named[5622]: zone example.com/IN: sending
notifies
(serial 2004011809)
Jan 18 18:45:13 localhost named: named reload succeeded
Jan 18 19:45:14 localhost named[5622]: client 192.168.128.3#32934: transfer
of 'example.com/IN': AXFR-style IXFR started
The output shows that the named daemon was reloaded and a change in example.com's zone file was detected. A NOTIFY message and associated serial number were then sent to all relevant addresses stored in NS records. Once the NOTIFY is received, slave name servers check with the master server and complete a zone transfer for the affected domain.
| Tip |
Notification keeps your master and slave name servers in synchronization. You might want to implement this setting globally in the options section of the master name server's /etc/named.conf file, if it is not already set. |
If you use notification to maintain your DNS updates, you might think that zone refresh rates don't even need to be established. After all, the master name server tells the slave name servers when a change has been made, right? Unfortunately, in the real DNS world this is not always the case.
Imagine what would happen if you had master and slave name servers configured properly and running cleanly, until one day the administrator of the LAN hosting your slave name server decides to install a firewall to protect his network. All of a sudden, your master name server's NOTIFY signals are being bounced, and the slave name server on Mr. Security'sLAN is not getting any updates. If you had set up standardized zone refresh settings on the slave name server, you would have far less of a problem.
Zone refresh settings are configured in the Start Of Authority (SOA) block in the slave name server's /etc/named.conf file. The default SOA block configured for localhost looks like this:
@ 1D IN SOA @ tom.yahoo.com (
20040117 ; serial number for zone
3H ; Refresh after 3 Hours
15M ; Retry after 15 Minutes
1W ; Expire after 1 Week
ID ) ; Negative TTL of 1 Day
In this example, we've added comments (in bold) that show what each setting does. These refresh settings affect the way in which the slave name server pulls down records and, when it cannot contact the master name server, how long the slave name server can continue to serve its data until the zone information must expire. Unless you are running a specialized BIND9 configuration (in which case you are probably not in need of this chapter), the default Refresh, Retry, and Expire values are usually sufficient. However, you might want to change the value of the Negative TTL field.
The Negative TTL field is fairly new in BIND configuration. It used to be called the Minimum TTL, but this is no longer the case. Minimum TTL functioned much like the zone-wide TTL at the top of each zone file:
$TTL 86400
Negative TTL, however, is the special Time To Live that caching name servers use when they provide negative, or false, responses. Such responses are issued when a name server receives a query for a domain name that does not have an associated zone or record. These negative responses can be cached and reissued without forcing the server to recheck the queried domain to see if anything exists yet. Just as caching DNS helps reduce the load on the Internet and on target DNS servers, so does this setting allows us to further reduce the load our DNS machine. If you do not have frequent requests for nonexistent domains, you are probably safe in leaving this set at the same value as the main TTL (by default, 1 day or 86,400 seconds).
| Note |
If you issue new DNS entries several times a day, you may need to change the Negative TTL value to a very low number. If you are adding new machines every day to an Internet-exposed network and want those new machines to be seen instantly, you will need to reduce the amount of time in which DNS servers claim that your new machines do not yet exist. |
|
|