DDNS, Notify and IXFR
ogud at tislabs.com
Fri Aug 13 18:40:40 UTC 1999
(This is a retransmission, bind-workers rejected it the first time).
In-Reply-To: <199908121828.LAA00192 at bb.rc.vix.com>
References: <Message from Jerry Scharf <scharf at vix.com>
<Pine.BSI.3.95.990812105857.22859I-100000 at sh.lh.vix.com>
Content-Type: text/plain; charset="us-ascii"
At 02:28 PM 8/12/99 , Bob Halley wrote:
>> 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
>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
Yes we need that, or we need to delete IXFR as a protocol and replace
with something MUCH better. I think that SOA update should be independent
of whether zone has IXFR allowed. NOTIFY logic should only be executed
after SOA is updated.
I think it is worth noting that update load that Kevin is reporting is
outside the parameters that the authors of dynamic update, notify and
IXFR had in mind.
>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).
The failure might be transient, thus attempting the update few seconds
later might succeed.
Your description is a good argument for using exponential back-off
algorithm for SOA updates. If there has not been update recently
client only gets ACK after SOA is updated.
Olafur Gudmundsson - NAI Labs
the Security Research Division of Network Associates, Inc.
ogud at tislabs.com Olafur_Gudmundsson at nai.com
Private: ogud at acm.org
More information about the bind-workers