Subject: [dnsext] axfr-clarify-10 section 3.2, Delegation Records

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 28 Jan 2009 16:36:09 +0200

draft-ietf-dnsext-axfr-clarify-10.txt section 3.2, discussing reasons
why AXFR responses must include glue records from the zone being transferred
rather than the corresponding authoritative records from a child, says:

    4) Beginning with an error state of two servers for a zone having
    inconsistent zone contents for a given zone serial number, if a client
    requests and receives an IXFR transfer from one server followed by 
    another IXFR transfer from the other server, the client can encounter
    an IXFR protocol error state where an attempt is made to incrementally
    add a record that already exists or to delete a record that does not
    exist.

    (Editorial note, the 4th reason was suggested, but I don't see how
    it relates.  A nudge for updated text on this.)

The quoted paragraph appears to be a somewhat mangled version of text
I suggested.  Perhaps the following would be clearer:

    4) This requirement is necessary to ensure that retrieving a given
    (zone,serial) pair by AXFR yields the exact same set of resource
    records no matter which of the zone's authoritative servers is
    chosen as the source of the transfer.

    If an AXFR server were allowed to respond with the authoritative
    NS RRset of a child zone instead of a glue NS RRset in the zone
    being transferred, the set of records returned could vary depending
    on whether or not the server happens to also be authoritative for 
    the child zone.

    The property that a given (zone,serial) pair corresponds to a
    single, well-defined set of records is necessary for the correct
    operation of incremental transfer protocols such as IXFR
    [RFC1995].  For example, a client may retrieve a zone by AXFR from
    one server, and then apply an incremental change obtained by IXFR
    from a different server.  If the two servers have different ideas
    of the zone contents, the client can end up attempting to
    incrementally add records that already exist or to delete records
    that do not exist.

-- 
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/>