Re: Bind 9 AXFR Modification vs AXFR Clarification

[Mark.Andrews@isc.org]

> On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote:
> 
> > > Good. You found a bug in an implementation. I thought such things were
> > > off-topic for this list.  This bug doesn't mean that AXFR is broken.
> > > Bind 8 did not have this bug, yet it has the common understanding of AXFR
> .
> > >
> > > Let me summarize the discussion:
> > >
> > > Everyone agrees that AXFR specification in RFC 1034 is ambiguous.
> > >
> > > Some people, many associated with Bind 9 development, assert that it is
> > > necessary to change AXFR to support IXFR.  This assertion has been refute
> d
> > > on the grounds that incremental database update does not depend on AXFR,
> > > since incremental database update does not depend on the underlying wire
> > > protocol used to create the remote database which is to be modified by
> > > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could
> > > still use IXFR, so, AXFR is independent of IXFR.
> >
> > 	Nobody is saying that preserving zone content is a *wire*
> > 	issue.  It is a server behaviour issue.
> 
> Zone definition and content is not an AXFR issue.  Server administrators
> provide the definition of zone boundaries. (RFC 1034 Section 2.3 and
> elsewhere)  AXFR merely gives the contents of the zone as has been defined
> according to the boundaries and content specified by the administrator.

	Well BIND 9 does this.  CISCO's server does this according
	to John.  BIND 8 doesn't always.  BIND 4 doesn't always.
	DJBDNS doesn't always.  This is independent of the method
	used to transfer the zone to these servers or enter the
	zone contents on these servers.

> The contents could be given to the secondary by FTP or other method.  If
> you mean to change the definition of zone contents, then I would say this
> proposal is hugely mis-labeled.

	It's not changing the definition.  It is preserving the
	definition.

	It's not mis-labeled.  It is stating the implict assumption
	that AXFR transfers what is entered as the zones contents.
	Nothing more, nothing less.

> All the IXFR server needs to do is determine (by some implementation
> dependent, administrator maintained method) what has changed between one
> zone version and another. How it does this is nobody's business but the
> administrator and the implementor. There are infinite possibilities, here.
> One could, for example, store differences in a series of files. The
> administrator could even make the differnce files by hand--this is an
> _implementation detail_. The IXFR server just sends a series or sequences
> consisting of a list of deleted RRs and a list of added RRs to an IXFR
> client. There is nothing more to it. (notwithstanding the optional
> condensation.)

	All of which is irrelevent to this issue.

> The IXFR client must simply make the changes (again, by some
> implementation dependent, administrator maintained method) to the zone by
> deleting RRs and adding RR's in each sequence. The original version of the
> zone might have been obtained by FTP (or quantum interference, or the
> psychic network) for all we know.

	Well the problem is that you have to get the *original* version,
	not a corrupted version.  AXFR implementations are not returning
	the data originally entered.
 
> This isn't rocket science, and doesn't require any AXFR changes. Nor does
> it require that the zone boundaries be defined only in some certain way,
> beyond the definition of zone boundaries given by the system
> administrator.

	It does however require that for a given serial number that all
	sources of the zone have supplied identical contents.  You should
	be able to apply a IXFR delta to a copy derived from any source
	and have it apply without error.
 
> > > Some people, many associated with Bind 9 development, assert that AXFR as
> > > commonly implemented by many implementors over many years, is broken, and
> > > can't transfer domains correctly.  This claim has been refuted by
> > > demonstration by interoperability between Bind 8 and other nameserver
> > > implementations over the years, and 77% of the internet that currently
> > > does not use Bind 9, yet still does AXFR.
> >
> > 	All this shows is that these nameservers are not used in
> > 	situations where the breakage is demonstrated or the
> > 	administators have learn to work around the breakage or
> > 	choose to live with it or are unaware of it.
> 
> "administrators have learn[ed] to work around [it,...] live with it [,] or
> are unaware of it".  Agreed.  Having done so, we don't want to stir the
> pot.

	LOL.
 
> Essentially, you are putting more (unnecessary) constraints on
> implementations, and thus on the administrators, who are supposed to be
> pretty free to define the zone boundaries.  Of course, the specifics of an
> implementation puts some constraints on the adminstrator, but the
> administrator can choose a different implementation more to her liking.

	The constaint was already there and it is necessary for reliable
	operation of the DNS.
 
> These unnecessary constraints are a "bad thing".
>
> > > To prevent confusion between the two proposals, I would like to rename th
> e
> > > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR
> > > Clarification". The term "axfr-clarify" will not be used.
> 
> I presume agreement on the name change?

	No.
> 
> 		--Dean
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org