Zone transfer is the process by which changes made on the primary server are replicated to all the secondary servers in the zone. There are three types of zone transfer to consider:
Full zone transfer
Incremental zone transfer
Full Zone Transfer
Originally, the only method of replication between primary and secondary servers was the full zone transfer. With this method, the entire zone database file is transferred whenever an update is made. The zone transfer is performed through a "pull" mechanism rather than a "push." This means that the secondary servers initiate the zone transfer. The process is as follows:
The secondary server waits a predetermined amount of time before contacting the primary server. When it does establish contact, it requests the primary server's Start of Authority (SOA) record. (Record types are discussed in depth in the "Resource Records" section later in this chapter.)
The primary server responds to the secondary server with its SOA record.
Whenever a change is made to the primary name server, the serial number held in the SOA record is incremented. When the secondary server receives the SOA record from the primary server, it compares the serial number to its own. If the serial number in the SOA record sent by the primary server is higher than the serial number in the SOA record currently on the secondary server, the secondary server knows its zone database is out of date. It then sends a request back to the primary server for a full zone transfer. This full transfer is done through an AXFR request.
The primary server then sends its full zone database file back to the secondary server. After the update is complete, the process begins again with the waiting period.
Incremental Zone Transfer
As you can probably imagine, performing a full zone transfer every time a single change is made to the primary server is inefficient. It also can generate a lot of network traffic if the primary server receives frequent updates and there are multiple secondary servers. To get around this problem, RFC 1995 allows for incremental zone transfers. As the name implies, with an incremental transfer, only the portion of the database that has been changed is replicated.
The process with an incremental transfer is the same as a full transfer, except with an incremental transfer, the secondary server sends an IXFR request, signifying an incremental transfer, rather than the AXFR request, which signifies a full zone transfer.
If you think of AXFR as A (all) XFR (transfer), it is easy to remember that AXFR is a full transfer. Likewise, you can think of IXFR as I (incremental) XFR (transfer).
For an incremental transfer to work, a version history must be kept so that name servers will know what changes have already been applied. The primary server maintains a version history, which keeps tracks of all changes that have been made since the last version update was transferred to a secondary server. When a secondary server requests an IXFR transfer, the primary server starts sending the recent updates, beginning with the oldest updates and progressing to the most recent updates.
When the secondary server begins receiving the updates, it creates a new version of the zone and begins applying the updates to that copy. When all the updates are committed to the copy of the zone database, the original database is replaced with the copy.
If the primary server does not support incremental transfers, it simply ignores the incremental request of the secondary server and performs a full zone transfer.
AD integrated zones are able to piggyback off of the standard AD replication scheme already in place on the network. Therefore, you do not have to manage a separate replication scheme for DNS data as you would if you used standard primary and secondary servers. AD replication is covered in Chapter 12.