[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dnsext] AXFR Clarify -- open issue w/ 'zone loading'

To the below, I added this as a separate paragraph.

"If a server rejects data contained in an AXFR session, the server
SHOULD remember the serial number and not attempt to retrieve the
same zone version again."

(Yeah, a one sentance-er.  Didn't want to mess with Alfred's work. ;))


At 1:13 +0200 9/5/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.
   With the massive amount of spam, it is easy to miss and therefore
   delete relevant posts by non-subscribers.
   Please fix your subscription addresses. ]

At the DNSEXT session in Dublin, the WG has committed to submit
text proposals for draft-ietf-dnsext-axfr-clarify-09, to address
the discussion point of 'AXFR operation' vs. 'Zone loading'.

Here is my proposal:

Add a new first paragraph to Section 6, "Zone Integrity" :

   An AXFR client MUST ensure that only a successfully transferred
   copy of the zone data can be used to serve this zone.  Previous
   description and implementation practice have introduced a two-stage
   model of the whole zone synchronization procedure: Upon a trigger
   event (e.g., polling of SOA resource record detects change in the
   SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session
   is initiated, whereby the zone data are saved in a zone file or
   data base (this latter step is necessary anyway to ensure proper
   restart of the server); upon successful completion of the AXFR
   operation and some sanity checks, this data set is 'loaded' and
   made available for serving the zone in an atomic operation, and
   flagged 'valid' for use during the next restart of the DNS server;
   if any error is detected, this data set MUST be deleted, and the
   AXFR client MUST continue to serve the previous version of the zone,
   if it did before.  The externally visible behavior of an AXFR client
   implementation MUST be equivalent to that of this two-stage model.


Kind regards,
  Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


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


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

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