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:
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.
|
