10.4 Incremental Zone Transfer (IXFR)

With dynamic update and NOTIFY, our zones are updated according to the changing state of the network, and those changes quickly propagate to all the authoritative name servers for those zones. The picture's complete, right?

Not quite. Imagine you run a large zone that's dynamically updated with frightening frequency. That's easy to envision: you might have a big zone to begin with, including thousands of clients, when all of a sudden management decides to implement Windows 2000 and DHCP. Now each of your clients updates its own address record in the zone, and the Domain Controllers update the records that tell clients which services they run. (There's much more to come on Windows 2000 in Chapter 16.)

Each time your primary master name server receives an update that increments the zone's serial number, it sends a NOTIFY announcement to its slaves. And each time they receive NOTIFY announcements, the slaves check the serial number of the zone on their master server and, possibly, transfer the zone. If that zone is large, the transfer will take some time—another update could arrive in the interim. Your slaves could be transferring zones in perpetuity! At the very least, your name servers will spend a lot of time transferring the whole zone when the change to the zone is probably very small (e.g., the addition of a client's address record).

Incremental zone transfer, or IXFR for short, solves this problem by allowing slave name servers to tell their master servers which version of a zone they currently hold and to request just the changes to the zone between that version and the current one. This can reduce the size and duration of a zone transfer dramatically.

An incremental zone transfer request has a query type of IXFR instead of AXFR (the type of query that initiates a full zone transfer), and it contains the slave's current SOA record from the zone in the authority section of the message. When the master name server receives an incremental zone transfer request, it looks for the record of the changes to the zone between the slave's version of the zone and the version the master holds. If that record is missing, the master sends a full zone transfer. Otherwise, it sends just the differences between the versions of the zone.

10.4.1 IXFR Limitations

Sound good? It is! But IXFR has a few limitations that you should know about. First, IXFR didn't work well until BIND 8.2.3. All BIND 9 name servers have IXFR implementations that work well and interoperate with BIND 8.2.3.

Next, IXFR works best when you're only modifying your zone data with dynamic updates. Dynamic updates leave a record of the changes made to the zone and the serial number changes they correspond to—exactly what a master name server needs to send to a slave that requests IXFR. But a BIND primary master name server that reloads an entire zone data file can't compute the differences between that zone and the previous zone. Nor can a BIND slave that gets a full zone transfer figure out what changed between that zone and the last.

This means that, to take maximum advantage of IXFR, you should modify your zone only by using dynamic update, and never edit the zone data file by hand.

10.4.2 IXFR Files

BIND 8 name servers maintain an IXFR log of changes to the zone separate from the dynamic update log file. Like the dynamic update log file, the IXFR log file is updated every time the name server receives an update. Unlike the dynamic update log file, the IXFR log file is never deleted, though the name server can be configured to trim it when it exceeds a particular size. The name of the BIND 8 IXFR log file, by default, is the name of the zone data file with .ixfr appended to it.

BIND 9 name servers use the dynamic update log file, or journal file, to assemble IXFR responses and to maintain the integrity of the zone. Since a primary master name server never knows when it may need the record of a particular change to the zone, it doesn't delete the journal file. A BIND 9 slave deletes the journal file if it receives an AXFR of the zone, since it now has a fresh full zone transfer and no longer needs to keep track of incremental changes to the last full zone transfer.

10.4.3 BIND 8 IXFR Configuration

Configuring IXFR in BIND 8 is fairly straightforward. First, you need an options substatement called maintain-ixfr-base on your master name server that tells it to maintain IXFR log files for all zones—even those the name server is a slave for, since those in turn may have slaves that want IXFRs:

options {
	directory "/var/named";
	maintain-ixfr-base yes;
};

Then you need to tell your slaves to request IXFRs from that master name server. You do that with a new server substatement, support-ixfr :

server 192.249.249.3 {
	support-ixfr yes;
};

That's about it, unless you want to rename the IXFR log file on the master. That's done with a new zone statement, ixfr-base :

zone "movie.edu" {
	type master;
	file "db.movie.edu";
	ixfr-base "ixfr.movie.edu";
};

Oh, and you can configure the name server to trim the IXFR log file after it exceeds a particular size:^[5]

^[5] Before BIND 8.2.3, you need to specify the number of bytes, rather than just "1M," because of a bug.

options {
	directory "/var/named";
	maintain-ixfr-base yes;
	max-ixfr-log-size 1M;     // trim IXFR log to 1 megabyte
};

Once the IXFR log file exceeds the specified limit by 100 KB, the name server trims it back to that size. The 100 KB of "slush" prevents the log file from reaching the limit and then being trimmed back after each successive update.

Using the many-answers zone transfer format can make zone transfers even more efficient. Take a look at Section 10.12.1.6 for details.

10.4.4 BIND 9 IXFR Configuration

It's even easier to configure IXFR in a BIND 9 master name server because you don't have to do a thing: it's on by default. If you need to turn it off for a particular slave server (and you probably won't, since a slave must request an incremental zone transfer), use the provide-ixfr server substatement, which defaults to yes :

server 192.249.249.1 {
	provide-ixfr no;
};

You can also use provide-ixfr as an options substatement, in which case it applies to all slaves that don't have an explicit provide-ixfr substatement of their own in a server statement.

Since BIND 9 master name servers send many-answers zone transfers by default, you don't need any special transfer-format configuration.

More useful is the request-ixfr substatement, which can be used in either an options or a server statement. If you have a mix of IXFR-capable and IXFR-impaired masters, you can tailor your slave's zone transfer requests to match the capabilities of its masters:

options {
	directory "/var/named";
	request-ixfr no;
};

server 192.249.249.3 {
	request-ixfr yes;     // of our masters, only terminator supports IXFR
};

BIND 9 doesn't support the max-ixfr-log-sizesubstatement.