DDNS, Notify and IXFR

[Olafur Gudmundsson]

(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>
Mime-Version: 1.0
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
>> 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
>future.

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. 

>
>Digression:
>
>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).
>
>/Bob
>
Two points: 
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
- ----------------------------------------------------
Olafur Gudmundsson - NAI Labs 
the Security Research Division of Network Associates, Inc.
ogud at tislabs.com  Olafur_Gudmundsson at nai.com
443-259-2389 
Private: ogud at acm.org