[BIND-BUGS #1025] 8.2.3-TB6 IXFR response violates spec

Mark Andrews Mark.Andrews at nominum.com
Sun Jul 23 15:19:07 UTC 2000


------- Blind-Carbon-Copy

To: "Eric A. Hall" <ehall at ehsco.com>
Cc: bind-bugs at isc.org
From: Mark.Andrews at nominum.com
Subject: Re: [BIND-BUGS #1025] 8.2.3-TB6 IXFR response violates spec 
In-reply-to: Your message of "Sat, 22 Jul 2000 01:13:46 MST."
             <397957BA.98A20798 at ehsco.com> 
Date: Mon, 24 Jul 2000 01:19:07 +1000

	Eric,
	      Please re-read RFC 1995, 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."

	The deltas between revisions are in two parts.
	1. the deletions started by the old SOA (100 in this case)
	2. the additions started by the new SOA (101 in this case)

	The additions end when a new delta is detected (new "old" SOA)
	or the terminating SOA is detected.

> 
> 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:
> 
	* tell the client what the final soa will be.
>     msg 1	SOA 102		(intro SOA of current version)

	* start of deletions.
> 		SOA 100		(slave version in intro; bogus)
> 

	* start of additions.
>     msg 2	SOA 101		(slave version+1)
>     msg 3	diffs from 100

	* start of deletions.
>     msg 4	SOA 101		(repeat?)
> 

	* start of additions.
>     msg 5	SOA 102		(slave version+2)
>     msg 6	diffs from 101
> 

	* signal end of IXFR
>     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.
> 
> I think the example is wrong in the IXFR clarifiction draft, but will
> address that separately.

	The example is correct and is in agreement with the paragraph
	cited.

> 
> Thanks
> 
> -- 
> Eric A. Hall                                      http://www.ehsco.com/
> Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

	Mark
- --
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com

------- End of Blind-Carbon-Copy



More information about the bind-workers mailing list