Re: Bind 9 AXFR Modification vs AXFR Clarification

[Mark.Andrews@isc.org]

> 
> 
> On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote:
> 
> > > 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.
> 
> THAT's what I have been saying. You were the one who said we needed to do
> this to support IXFR. I've been saying that claim was wrong. Thanks for
> FINALLY coming round to that.
> 
> > > 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 th
> e
> > > 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.
> 
> They sure have been.

	Not always.
 
> > > 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.
> 
> None of this is relevant. All that is necessary is to delete the RRs, and
> insert the RRs in the sequence.
> 
> If the zones are inconsistent through administrative mistake, then it
> won't matter what the IXFR does.

	Who said anything administrative mistakes?  The content is being
	unilaterally changed by the servers.
 
> > > > > Some people, many associated with Bind 9 development, assert that AXF
> R 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 currentl
> y
> > > > > 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 [,] o
> r
> > > are unaware of it".  Agreed.  Having done so, we don't want to stir the
> > > pot.
> >
> > 	LOL.
> 
> Strange, that was my reaction, too. I'm just trying to be polite.  77%
> work just fine. We don't want to break 77% of the servers out there.

	You really think that it will break those servers?  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 a
> n
> > > 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.
> 
> No, you ware not being honest about the contents of the Draft. See my last
> message to Andreas.

	The abstract say:

				    This memo clarifies, updates, and
   adds missing detail to the original AXFR protocol specification in
   RFC1034.

	I fail to see how the contents can be deemed misleading when
	it states up front what it does.  Woops we missed warning you
	up front that it contains a warning.
 
> > > > > To prevent confusion between the two proposals, I would like to renam
> e th
> > > e
> > > > > first proposal "Bind 9 AXFR Modification", and the second proposal "A
> XFR
> > > > > Clarification". The term "axfr-clarify" will not be used.
> > >
> > > I presume agreement on the name change?
> >
> > 	No.
> 
> Then the entire draft should be rejected since it is misleading.  Please
> resubmit a proposal that isn't misleading the community about its purpose,
> impact, and contents.
> 
> 		--Dean

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