UNIX System Administration Handbook - Evi Nemeth [263]
Instead of just waiting passively for slave servers to time out, BIND servers now notify their slaves every time a zone changes, unless the notify parameter is specifically turned off in the configuration file. Slaves that understand the notification act immediately to refresh themselves.
If a slave server tries to check the master’s serial number but the master does not respond, the slave tries again after the retry timeout period has elapsed. Our experience suggests that 20–60 minutes (1,200–3,600 seconds) is a good value.
If a master server is down for a long time, slaves will try to refresh their data many times but always fail. Each slave should eventually decide that the master is never coming back and that its data is surely out of date. The expire parameter determines how long the slaves will continue to serve the domain’s data authoritatively in the absence of a master. The system should be able to survive if the master server is down for a week, so this parameter should have a longish value. We recommend a week to a month.
Prior to BIND 8.2, the minimum parameter set the default time to live for resource records. It was included with each record and used to expire the cached records on nonauthoritative servers. As of BIND 8.2, the meaning of the minimum parameter in the SOA record has changed. It now sets the time to live for negative answers that are cached. The default for positive answers (i.e., actual records) is specified at the top of the zone file with the $TTL directive. Experience suggests values between a few hours and several days for $TTL and an hour or two for the minimum. minimum cannot be more than three hours.
The $TTL, expire, and minimum parameters eventually force everyone that uses DNS to discard old data values. The design of DNS relied on the fact that host data was relatively stable and did not change often. However, DHCP and mobile hosts have changed the rules. BIND is desperately trying to cope by providing the dynamic update and incremental zone transfer mechanisms described starting on page 458. For more information about TTLs and a concept called TTL harmonization, see page 454.
NS records
NS (name server) records identify the servers that are authoritative for a zone (that is, all the master and slave servers) and delegate subdomains to other organizations. NS records usually follow the SOA record.
The format is
zone [ttl] IN NS hostname
For example:
cs.colorado.edu. IN NS ns.cs.colorado.edu.
cs.colorado.edu. IN NS anchor.cs.colorado.edu.
cs.colorado.edu. IN NS ns.cs.utah.edu.
Since the zone name is the same as the name field of the SOA record that precedes these NS records, it can be left blank. Thus, the lines
IN NS ns.cs.colorado.edu.
IN NS anchor.cs.colorado.edu.
IN NS ns.cs.utah.edu.
immediately following the SOA record for cs.colorado.edu would be equivalent.
Every authoritative name server for cs.colorado.edu should be listed both in the zone file for cs.colorado.edu and also in the file for the parent zone, colorado.edu. Caching-only servers cannot be authoritative; do not list them. No parameter in the NS records specifies whether a server is a master or a slave. That information is specified in the named.conf file.
named uses a zone’s NS records to identify slave servers when it wants to send out notifications of changes to the zone. Those same NS records inside the parent zone (colorado.edu) define the cs subdomain and delegate authority for it to the computer science department’s name servers. If the list of name servers in the parent zone is not kept up to date with those in the zone itself, any new servers that are added become stealth servers and are not used to answer queries from the outside world. This situation happens sometimes through design and sometimes through forgetfulness.
A quick look at our own delegations revealed a major server for colorado.edu that the edu domain