DDNS, Notify and IXFR

Bob Halley Bob_Halley at iengines.net
Thu Aug 12 18:28:21 UTC 1999

> Why should an IXFR ever cause a serial number update? My view is that
> serial numbers are indicators of zone content change and an IXFR doesn't
> change content any more than an AXFR. Since all dynamic updates are pushed
> up to the master, it should be the only one doing the serial number
> changes.

If the updates do not change the SOA serial directly, BIND 8 will try
to defer the serial number update in the hopes that two or more
updates can be batched into one serial number change.  Whenever the
SOA of the zone is going to become visible, e.g. because of an IXFR,
the deferred serial number update must be executed.

I think we're going to need to rate-limit NOTIFY generation in the


BIND 9 does not try to do deferred serial number updates.  BIND 9
doesn't know how the data in its databases is stored (indeed, the data
could be in a SQL database on another system), so it cannot do what
BIND 8 does and directly increment the memory containing the SOA
serial.  Updating the serial also will require re-signing the SOA
record in secure zones.  Making these changes involves a database
update, which could fail.  If we allowed deferred serial number
updates, we could find ourselves in a situation where we've said "yes,
your update was successful" to the client, but the deferred serial
number update fails for some reason.  Now we're really in trouble
because the state we're in is inconsistent and we can't get out of it
without either updating the serial (which is failing) or rolling back
the update (violating our promise to the client).


More information about the bind-workers mailing list