4.3 Mô hình hoạt động của hệ thống DNS
4.3.4 Cập nhật dữ liệu zone
(Aitchison, 2011) - Zone Maintenance
In order to simplify the operation of multiple name servers, it is useful if a single source can update multiple servers. This process—zone maintenance—can involve transfer of zone files from one DNS server to another—between a master and slave DNS for the zone—using features of the DNS protocol.
The time between transferring zone file changes is a major determinant of the speed with which
changes to the zone information are propagated throughout the Internet. The initial design of DNS allowed for changes to be propagated using full zone transfer (AXFR) operations, but the world of the Internet was simpler and more sedate in those days (1987). The desire to speed up the process of zone update propagation, while minimizing use of resources, has resulted in a number of changes to this aspect of DNS design and implementation from simple—but effective—tinkering such as incremental zone transfer (IXFR) and NOTIFY messages to the more complex concept of dynamic update (DDNS).
_Warning While zone transfers are generally essential for the efficient operation of DNS systems, they are also a
major source of threat. A slave DNS can become poisoned if it accepts zone updates from a malicious source. Care
should be taken during DNS configuration to ensure that, as a minimum, the slave DNS will accept transfers from
only known and trusted sources. The example configurations provided in later chapters implement these minimum
precautions.
Full Zone Transfer ( AXFR)
The original DNS specifications (RFC 1034 and RFC 1035) envisaged that slave (or Secondary) name servers for the zone would poll the master name server for the zone. The time between polling is determined by the refresh value of the domain’s SOA RR, which was described in Chapter 2. In a typical zone file, this value will be 12 hours or more.
The DNS polling process is accomplished by the slave name server sending a query to the zone
master requesting the SOA RR. If the SOA RR’s serial number is greater than the current one maintained by the slave name server, a full zone transfer (AXFR) is requested by the slave DNS. This is the reason it is vital to be disciplined about updating the SOA serial number every time anything changes in any of the zone records. The following example demonstrates updating the serial number using the recommended date number format of yyyymmddss, where yyyy is a four-digit year number, mm is a two-digit month number, dd is a two-digit day number, and ss is a sequence number so that the zone can be updated more than once per day. Assume an SOA RR as shown here:
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080803 ; sn = serial number 3h ; refresh time
15m ; retry = refresh retry 3w ; expiry
3h ; nx = nxdomain ttl )
Using the date format, this shows that this zone file was last updated four times (ss = 03) on August 8, 2003. If we assume that today’s date is September 7, 2003, then the serial number should be set to the value shown here:
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003090700 ; sn = serial number
3h ; refresh time
15m ; retry = refresh retry 3w ; expiry
3h ; nx = nxdomain ttl )
The sequence number has also been reset to 00 to ensure we have plenty of space for fixing errors! If the month and date of the preceding example were to be swapped in error, then the serial number would be
2003070900 ; sn = serial number
This number is not greater than the previous number, so the slave would not request a zone transfer and the updates would not be propagated. The fix in this case is simple because the error is back in time.
The following example shows the serial number being incorrectly placed forward in time:
2005090700 ; sn = serial number
To restore this serial number to the correct date is much more complex, and you would want to do it only once in your life. The procedure is documented in Chapter 8. Remember that the date format is a widely used and recommended convention; BIND does not validate the number for correct ranges, that is, the following is accepted quite happily by BIND, which is the 45th day of the 14th month of 2003!:
2003144500 ; sn = serial number
In this case, a zone transfer will take place because the number is greater than our initial value.
Zone transfer (AXFR) operations use TCP on port 53.
_Warning Not updating the serial number field of the SOA RR when any change is made to the zone file is one of
the most common causes of head scratching, screaming, and other more seriously aberrant behavior when
dealing with DNS systems. Always update the SOA RR serial number when you make any changes to a zone file.
Incremental Zone Transfer ( IXFR )
Transferring very large zone files can take a long time and waste bandwidth and other resources. It is especially wasteful if only a single record has been changed! RFC 1995 introduced the incremental zone transfer (IXFR), which (as the name suggests) allows the slave name server and master name server to transfer only those records that have changed.
The process works as for AXFR. The slave name server sends a query for the domain’s SOA RR to the zone master every refresh interval. If the serial number of the SOA RR is greater than the one currently stored by the slave, the name server requests a zone transfer and indicates whether or not it is capable of accepting an IXFR. If both master and slave name servers support the feature, an IXFR takes place;
otherwise, an AXFR takes place. IXFRs use TCP on port 53.
The default mode for BIND when acting as a slave name server is to request IXFR unless it has been configured not to by use of the request-ixfr statement in the server or options clause of the named.conf file (see Chapter 12 for details).
The default mode for BIND when acting as a master name server is to use IXFR only when the zone is dynamic. The use of IXFR is controlled through the provide-ixfr statement in the server or options clause of the named.conf file (see Chapter 12 for details).
IXFRs affect only the volume of data that is transferred; they have no impact on the time it takes to propagate zone file changes.
Notify ( NOTIFY)
RFC 1912 recommends an interval of 2 to 12 hours or higher on the refresh interval for the SOA RR. This means that changes to the zone master may not be visible to the zone slave for up to 12 hours or whatever this value is set to. In the fast-moving world of the Internet, this may be unacceptable.
RFC 1996 introduced a scheme whereby an authoritative zone name server (either master or slave) will send a NOTIFY message to the zone name servers (defined by the NS RRs for the zone) whenever the zone is loaded or updated. This message indicates that a change may have occurred in the domain records. The name server on receipt of the NOTIFY message will request the SOA RR from the zone
master, and if the serial number is greater than the one currently stored, will attempt a zone transfer using either an AXFR) or an IXFR.
BIND’s default behavior is to send NOTIFY messages to name servers that are defined in the NS RRs for the zone. NOTIFY behavior in BIND is controlled by notify, also-notify, and notify-source
statements in the zone or options clauses of the named.conf file (see Chapter 12 for details).
NOTIFY can considerably reduce the time to propagate zone changes to servers.
Dynamic Update
The classic method of updating zone RRs is to manually edit the zone file and then stop and start the name server to read the zone files and propagate the changes. When the volume of changes reaches a certain level, this can become operationally unacceptable—especially considering that in organizations that handle large numbers of zone files, such as service providers, BIND can take a long time to restart because it initializes very large numbers of zone files.
Many larger users of DNS seek a method to rapidly change the zone records while the name server continues to respond to user queries. There are two architectural approaches to solving this problem:
Allow runtime updating of the zone RRs from an external source or application.
Directly feed the zone RRs from a database, which can be dynamically updated.
RFC 2136 takes the first approach and defines a process, called Dynamic DNS (DDNS), whereby zone records can be updated from one or more external sources. The key limitation in this specification is that a new domain or zone cannot be added or deleted dynamically. All records within an existing zone can be added, changed, or deleted—with the exception that the SOA RR cannot be added or deleted because this would essentially add or remove the zone.
As part of RFC 2136, the term primary master was introduced to describe the name server defined in the SOA RR for the zone. When dynamically updating zone RRs, it is essential to update only one server, even though there may be multiple master servers for the zone. In order to solve this problem, a boss server must be selected. The boss server, the primary master, has no special characteristics other than it is defined as the name server in the SOA RR and may appear in an allow-update statement of BIND’s named.conf configuration file to control the dynamic update process (see Chapter 12 for details).
DDNS is normally described in conjunction with Secure DNS features—specifically, TSIG (RFC 2845) and TKEY (RFC 2930). DDNS, however, does not require or rely on TSIG/TKEY features.
The reason why the two features are tightly coupled is that by enabling Dynamic DNS, zone files may be opened up to the possibility of corruption or poisoning by malicious sources. Simple IP address protection can be configured into BIND (using BIND’s allow-update statement described in Chapter 12), but this provides limited protection. System architecture can further remove risk by positioning both the target name server and all the hosts that are allowed to update it behind secure perimeters. The real power, however, of DDNS is that remote and distributed users are able to semiautonomously update and control their domain configurations. Under these circumstances, serious users of Dynamic DNS will always use TSIG/TKEY procedures, described in Chapter 10, to authenticate incoming requests.
BIND’s default DDNS behavior is to deny from all hosts. Control of dynamic update is provided by
the BIND named.conf statements allow-update (usable with and without TSIG/TKEY) and update-policy (usable only with TSIG/TKEY) in the zone or options clauses. The statements and clauses mentioned are described in Chapter 12.
There are a number of Open Source tools that will initiate DDNS updates; they include nsupdate, which is one of the utilities distributed with BIND (and described in Chapter 9).
Alternative Dynamic DNS Approaches
As noted earlier, the major limitation in DDNS (RFC 2136) is that new domains cannot be created dynamically. Alternative approaches to this problem do exist.
BIND-DLZ (code base integrated into BIND since release 9.4) takes a much more radical approach and replaces all zone files with a single zone file that simply describes a database. BIND-DLZ supports the major Open Source databases including MySQL, PostgreSQL, BDB, and LDAP. All incoming DNS queries are first directed to the database access routines so that new, modified, or deleted zone data is immediately reflected in the name server’s responses. As with all things in life, there is a trade-off.
Depending on the selected database, performance can drop precipitously. BIND-DLZ database drivers are included in the /contrib directory of a BIND release (since 9.4). For BIND-DLZ configuration information, the latest database drivers and performance data use the BIND-DLZ web site (binddlz.
sourgeforge.net).
PowerDNS (www.powerdns.com) is an authoritative-only name server that takes a similar approach with its own (non-BIND) code base by referring all queries to the database back-end and thereby allowing new domains to be added dynamically.
BIND 10 (described in Chapter 14) supports full dynamic creation and deletion of zones using a
database back-end (the default is SQLite). Standard text zone files may be loaded into the database using the new loadzone utility.
_Caution The use of real-time changes to DNS records without the proper safeguards can result in trivial errors
being immediately propagated throughout the Internet with potentially catastrophic consequences.
Because DNS
caches will typically hold such records for 12 or more hours (determined by either the $TTL for the zone file or the
TTL value for the specific RR), such errors can take a long time to correct.