Subject: [dnsext] axfr-clarify-10 and rapidly changing zones

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 29 Jan 2009 11:54:09 +0200

draft-ietf-dnsext-axfr-clarify-10.txt section 3.1 states:

  Zones for which it is impractical to list the entire zones for a serial
  number (because changes happen too quickly) are not suitable for AXFR
  retrieval.  A typical (but not limiting) description of such a zone
  is a zone consisting of responses generated via other database lookups
  and/or computed based upon ever changing data.  In essence, if the
  zone changes (on average) more frequently than and AXFR session can be
  finished, the zone is not a good candidate for AXFR.

While it's true that there are zones that are impractical to transfer
by AXFR, a zone changing more quickly than the AXFR session can be
finished does not by itself make it unsuitable for AXFR.  Existing
implementations handle this case just fine, transmitting a coherent
snapshot of the zone contents as of the time when the transfer started
and continuing to update the zone (e.g., by dynamic update) while the
transfer progresses, without affecting the version being transferred.

The transferred zone will of course be out of date by the time the
transfer finishes, but slave zones have never been guaranteed to be
up-to-date in any case (due to the REFRESH interval, etc).  And even
in cases where a close coherency between master and slave is
operationally desired, it's perfectly reasonable to do an initial AXFR
during which multiple updates to the zone take place, and then bring
the slave up-to-date by a subsequent IXFR.

I suggest removing the references to changes happening "too quickly"
or "more frequently than and (sic) AXFR session can be finished",
leaving just the following text:

  Zones for which it is impractical to list the entire zones for a serial
  number are not suitable for AXFR retrieval.  A typical (but not limiting)
  description of such a zone is a zone consisting of responses generated
  via other database lookups and/or computed based upon ever changing data.

-- 
Andreas Gustafsson, [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>