DNS zone transfer, also sometimes referred known by its (commonest) opcode mnemonic AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to employ for replicating the databases containing the DNS data across a set of DNS servers. Zone transfer comes in two flavours, full (opcode AXFR) and incremental (IXFR). Whilst nearly universal at one time, it is now falling by the wayside somewhat, in favour of the use of other database replication mechanisms that modern DNS server packages provide.
Operation
Zone transfer operates on top of the Transmission Control Protocol (TCP), and takes the form of a client-server transaction. The parties involved in a zone transfer are a client, the "slave" requesting the data from a portion of the database to be transferred to it, and a server, the "master" supplying those data from its database. (Some sources refer to the slave as a "secondary" server and the master as a "primary" server.) The portion of the database that is replicated is a "zone".
Zone transfer comprises a preamble followed by the actual data transfer. The preamble comprises a lookup of the SOA resource record for the "zone apex", the node of the DNS namespace that is at the top of the "zone". The fields of this SOA resource record, in particular the "serial number", determine whether the actual data transfer need occur at all. The client compares the serial number of the SOA resource record with the serial number in the last copy of that resource record that it has. If the serial numbers differ, the data in the zone are deemed to have "changed" (in some fashion) and the slave proceeds to request the actual zone data transfer. If the serial numbers are identical, the data in the zone are deemed not to have "changed", and the client may continue to use the copy of the database that it already has, if it has one.
The actual data transfer proper begins by the client sending a query with the special opcode AXFR (value 252) over the TCP connection to the server. The server responds with a series of response messages, comprising all of the resource records for every domain name in the "zone". The first response comprises the SOA resource record for the zone apex. The other data follow in no specified order. The end of the data are signalled by the server repeating the response containing the SOA resource record for the zone apex.
Some zone transfer clients perform the SOA lookup of the premable using their system's normal DNS query resolution mechanism. These clients do not open a TCP connection to the server until they have determined that they need to perform the actual data transfer. However, since TCP can be used for normal DNS transactions, as well as for zone transfer, other zone transfer clients perform the SOA lookup preamble over the same TCP connection as they then (may) perform the actual data transfer. These clients open the TCP connection to the server before they even perform the preamble.
The preceding describes full zone transfer. Incremental zone transfer differs from full zone transfer in the following respects:
- The client uses the special opcode IXFR (value 251) instead of the AXFR opcode.
- The client sends the SOA resource record for the zone apex that it currently has, if any, in the IXFR message, letting the server know which version of the "zone" it believes to be current.
- Whilst the server may respond in the normal AXFR manner with the full data for the zone, it may also instead respond with an "incremental" data transfer. This latter comprises the list of changes to the zone data, in zone serial number order, between the version of the zone that the client reported to the server as having and the version of the zone that is current at the server. The changes comprise two lists, one of resource records that are deleted and one of resource records that are inserted. (A modification to a resource record is represented as a deletion followed by an insertion.)
Zone transfer is entirely client-initiated. Whilst servers can send a NOTIFY message to clients (that they have been informed about) whenever a change to the zone data have been made, the scheduling of zone transfers is entirely under the control of the clients. Clients schedule zone transfers initially, when their databases are empty, at thereafter at regular intervals, in a pattern controlled by the values in the "refresh", "retry", and "expire" fields in the SOA resource record of the zone apex.
Limitations
Whilst it is standardized, full zone transfer being described as one of the possible database replication mechanisms in RFC 1034 (with incremental zone transfer described in RFC 1995), zone transfer is the most limited of those database replication mechanisms. This is largely due to a mismatch of database schemata. Zone transfer operates in terms of "wire format" resource records, i.e. resource records as they are transferred using the DNS protocol via TCP and UDP. However, the schema of wire format resource records rarely matches the database schemata used by the back ends of the DNS servers themselves. It is thus impossible to fully replicate the actual database contents using zone transfer as the replication mechanism.
For modern DNS server packages, it is almost never the case that the database schemata actually used by the servers match that of zone transfer. Microsoft's DNS server has timestamp and security information fields in resource records that zone transfer is incapable of transferring. djbdns has time-to-die and location information fields in resource records that zone transfer is incapable of transferring. Even ISC's BIND has information in its back end database, such as the $GENERATE directive, that is impossible to directly transfer using zone transfer.
Operational problems
There are several interoperability and operational problems that occur with zone transfer.
Serial number changes
The preamble portion of zone transfer relies on the serial number, and only the serial number, to determine whether a zone's data have changed, and thus the actual data transfer is required. For some DNS server packages, the serial numbers of SOA resource records are maintained by administrators by hand. Every edit to the database involves making two changes, one to the record being changed and the other to the zone serial number. This is a laborious process and one that is prone to error, with administrators either forgetting to change a serial number or changing a serial number incorrectly (such as decreasing it or increasing it by a huge amount).
Some DNS server packages have overcome this problem by automatically constructing the serial number from the last modification timestamp of the database file on disc. This is the case for djbdns, for example. The operating system ensures that the last modification timestamp is updated whenever an administrator edits the database file, effectively automatically updating the serial number, and thus relieving administrators of the need to make two edits (in two different places) for every single change.
Furthermore, the paradigm of database replication for which the serial number check (and indeed zone transfer itself) is designed, which involves a single central DNS server holding the master version of the database with all other DNS servers merely holding copies, simply does not match that of many modern DNS server packages. Modern DNS server packages with sophisticated database back ends such as SQL servers and Active Directory allow administrators to make updates to the database in multiple places (such systems being said to be "multi-master"), with the database back end's own replication mechanism handling the replication to all other servers. This paradigm simply does not match that of a single, central, monotonically increasing number to record changes, and thus is incompatible with zone transfer to a large extent. Modern DNS server packages with sophisticated database back ends often will create a "shim" serial number, simulating the existence of a single central place where updates are made, but this is at best imperfect.
Fortunately, for this and several reasons outlined later, DNS servers that use such sophisticated database back ends in general rarely use zone transfer as their database replication mechanism in the first place, and usually instead employ the vastly superior distributed database replication mechanisms that the back ends themselves provide.
Serial number comparisons
Not all clients perform the serial number check, in the preamble, in the same way. Some clients check merely that the serial number supplied by the server is different to that known by the client, or non-zero. Other clients check that the serial number supplied by the server is within a given range of the serial number already known by the client. Yet other clients still perform the latter check and additionally check that the serial number supplied by the server is zero.
Multiple resource records
Originally, in the actual data transfer each set of resource records for a single domain name and type was transferred in a separate response message from the server to the client. However, this is inefficient, and some DNS server softwares took to implementing optimizations, geared at allowing the response compression mechanism in the DNS protocol to reduce the total bandwidth requirements of data transfers, such as:
- performing "additional section processing" to include any "glue" resource record sets in the same response as an NS, SRV, or MX resource record set
- collecting all of the resource record sets relating to a single domain name together and sending them, if they fit, in a single response
Some clients were written to expect only the original response format, and would fail to perform data transfer if such optimization were employed. Several DNS server packages thus have a configuration setting allowing administrators to specify the use of "single answer format" responses for those clients that require it.
Security
Zone transfer is often seen as being a major security issue for network administrators. However, some of the purported security problems with it are considered either mis-placed or ill-founded by experts.
Security through obscurity
Zone transfer is seen as a way for "hackers" to obtain the entire content of a "zone" in one go, for later analysis. This is often seen as a bad thing. However, experts opine that this view fails to take into account two factors.
First, it fails to take into account the fact that providing DNS service is inherently publication. All data available via zone transfer are also available via normal DNS transactions, and thus published. Claims that zone transfer weakens security by allowing "hackers" to obtain "private" data are founded in the fundamental misconception that the data are in fact private in the first place, when in actuality they are not. Addressing zone transfer as a problem, when in fact the real problem is the poor choice of what data to publish and what data not to publish, is addressing the wrong problem.
Second, it fails to take into account the fact that denying zone transfer access does not stop this, since the extensions to the DNS protocol implemented in DNS servers that implement the DNS Security extensions (DNSSEC) allow anyone to obtain exactly the same data as they would via a zone transfer using a technique known as "NXT walking".
Denial of (front-end) service
Zone transfer is seen as a way for "hackers" to perform denial of service attacks against DNS servers, by performing spurious zone transfer attempts. DNS servers, or the operating systems that they run on, often limit the number of simultaneous TCP connections to a server, and attackers can consume all available connections, denying service to legitimate users. Attackers can also perform repeated zone transfers, consuming all available bandwidth.
However, experts opine that these are problems in TCP itself, and are inherent in any service provided via TCP, not just DNS zone transfer. Moverover, since normal DNS transactions may also be performed via TCP, they are not limited to zone transfer alone even when one is considering DNS services specifically.
Denial of (back-end) service
Zone transfer is seen as a way for "hackers" to perform denial of service attacks against DNS administrators. Zone transfer implicitly requires that a "snapshot" of the database be taken, so that the actual data transfer itself provides the client with a self-consistent view of the zone's data. With some DNS server packages, this can cause the database back-end to become locked against writing for the entire duration of a zone transfer. Attackers who perform repeated zone transfers continually (and slowly) can thus cause the database to be permanently locked against writing, preventing administrators from updating any records.
This problem is largely minimized, in the cases of the DNS servers that use sophisticated database back ends such as SQL servers and Active Directory that would have to perform such write locking, simply by dint of the fact that in such cases zone transfer is rarely, if ever, the database replication mechanism employed in the first place, since such back ends often provide vastly superior distributed database replication mechanisms of their own.
References
Last updated: 10-18-2005 15:12:19
