"Eric A. Hall": [BIND-BUGS #1025] 8.2.3-TB6 IXFR response violate s spec

Kevin J. Dunlap kevind at metaip.checkpoint.com
Sun Jul 23 19:16:13 UTC 2000


BIND 8.2.3-T6B IXFR protocol looks correct to me.

Eric, needs to understand the SOA bracketing that separates adds and deletes
in the IXFR protocol.

RFC 1995 and Draft-ietf-dnsext-ixfr-01.txt, Section 4, Paragraph 3:

"Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR
of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR."


Msg1 is telling the requester to delete the SOA with serial number 100.
Msg4 is telling the requester to delete the SOA with serial number 101.

-Kevin

At 08:11 AM 07/22/2000 -0700, Paul A Vixie wrote:
>yo, kevin!
>
>------- Forwarded Message
>
>There seems to be a bug in the IXFR clarification spec recently
>submitted, but regardless of that, there are some formatting issues with
>the IXFR handling in BIND 8.2.3-TB6:
>
>Given a slave version of 100, a master version of 102, and two
>intermediary changes, the spec response is:
>
>     msg 1       SOA 102         (intro; SOA of current version)
>
>     msg 2       SOA 101         (slave version+1)
>     msg 3       diffs from 100
>
>     msg 4       SOA 102         (slave version+2)
>     msg 5       diffs from 101
>
>     msg 6       SOA 102         (outro)
>
>
>BIND 8.2.3-TB6's behavior doesn't follow that format. For example:
>
>     msg 1       SOA 102         (intro SOA of current version)
>                 SOA 100         (slave version in intro; bogus)
>
>     msg 2       SOA 101         (slave version+1)
>     msg 3       diffs from 100
>     msg 4       SOA 101         (repeat?)
>
>     msg 5       SOA 102         (slave version+2)
>     msg 6       diffs from 101
>
>     msg 7       SOA 102         (outro/repeat?)
>
>The principle formatting errors are:
>
>  1) msg1 should ONLY contain the current SOA
>
>  2) msg4 should not exist
>
>Looks like you're jumping into the SOA counter loop while you're still
>in the intro section, throwing the other SOA writes off by one.






More information about the bind-workers mailing list