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

Re: in support of axfr-clarify



> It would make the standards transaction more intellectually honest.
> 
> But I still think the changes are dubious.  I assert that the AXFR
> protocol and semantics should not need to be changed in order to do IXFR.
> Changes to the AXFR semantics seems to imply changes to RFC1035, and
> affects backward compatibility.  I think tampering with AXFR is risky, and
> not well understood.
> 
> However, I haven't looked into the Bind 9 IXFR modifications enough to
> know exactly why AXFR changes are really necessary, or if indeed they are
> really necessary or just a convenient hack to make IXFR work in Bind.
> 
> I think I would rather change IXFR to make it work without changes to
> AXFR.
> 
> So I still wouldn't be for it.

	The rules are required for basic AXFR to work regardless of
	IXFR.

	Take the following senario.

	A is the primary master for example.net.
	B is the primary master for child.example.net.
	C is a server for example.net and child.example.net.
	D is a server for example.net that uses C as a master.

	A and B both change the NS RRset for child.example.net.
	The NOTIFY from B is lost so the update relies on refresh.
	C transfers example.net.  C replaces the NS RRset with that
	from child.example.net.
	C notifies D that it has a new version of example.net.
	D transfers example.net from C.
	C performs a refresh query for child.example.net and transfers it.

	You now have:

	A with the NEW NS RRset for child.example.net.
	B with the NEW NS RRset for child.example.net.
	C with the NEW NS RRset for child.example.net.
	D with the OLD NS RRset for child.example.net.

	This is why you MUST preserve zone contents with AXFR.

	Mark

> 
> 		--Dean
> 
> On 27 Nov 2002, Greg Hudson wrote:
> 
> > On Wed, 2002-11-27 at 16:32, Dean Anderson wrote:
> > > It seems highly inappropriate to make seemingly gratiutous changes in a
> > > particular commercial product, begin distributing those changes to users,
> > > and then attempt to change the standards to reflect the changes, and
> > > describing those changes as a "clarification".
> >
> > Would it really make any of you happier if the title were changed from
> > "clarifications" to "revisions" and the introductory text modified
> > accordingly?  (If so, I'm all for it.)
> >
> >
> 
> 
> 
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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