Re: Bind 9 AXFR Modification vs AXFR Clarification

[Mark.Andrews@isc.org]

> > > > > The IXFR client must simply make the changes (again, by some
> > > > > implementation dependent, administrator maintained method) to the zon
> e by
> > > > > deleting RRs and adding RR's in each sequence. The original version o
> f 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 returnin
> g
> > > > 	the data originally entered.
> > >
> > > They sure have been.
> >
> > 	Not always.
> 
> You haven't shown any proof of that.  The "proof" you showed, was the
> result of a misconfiguration.

	No.  It is the result of operational reality.  Whenever you
	have a parent and child zones under different administrative
	controls it is impossible to change both zones simultaniously.
	It is also impossible using AXFR or any other mechanism
	which transfers *individual* zones to transfer them to a
	secondary and guarantee that they will arrive simultaniously.

	Having parent and child zone under different administrative control
	is the norm not the execption.

> > > 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.
> 
> It is reasonable and necessary to merge in glue. When you misconfigure the
> glue, strange things may happen. That is all that you have shown.  I'm
> sure that many software programs will exhibit even stranger behavior, and
> may even fail to operate as a result of misconfiguration.

	No.  It is neither reasonable nor necessary.  Any temporary
	inconsistancies will be corrected when all the zone transfers
	complete.  By changing the zones contents you create
	situations where these temporary inconsistancies won't be
	corrected.  When handing out non axfr/ixfr responses you
	use the best source of data you have.

	Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted
	to alter the content of a zone.  The responability for maintaining
	consistancy between zones is a administrative function.
 
> > > 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.
> 
> They will not be compliant, and thus will need to be changed. Thus, they
> would be broken by definition of not being compliant.

	So.  Just because they will not be compliant doesn't mean
	that that they need to be replaced immediately.  That
	non-compliance doesn't hurt most of them.  For those where
	it does have a negative impact it will mean that they should
	be able to request a fix from their vendor.

> Your failure to comprehend the consequences of the changes does not lessen
> the effect.  We now agree that these changes aren't necessary to support
> IXFR. You were part of the bad engineering that led to the unnecessary
> creation of these changes in Bind 9.  You were also part of the bad
> decision making that led to the distribution of these changes to Bind 9
> users prior to standardization, and quite possibly you were part of the
> bad decision making that resulted in publishing a book on the subject,
> prior to acceptance of your modifications to standards. In short, you have
> shown bad judgement.

	I never said that they we not necessary for IXFR.  I said that
	that your descripition of how to generate the differences was
	irrelevent to this discussion.

	It was bad engineering to merge the data sets together in the
	first place.  It was not required by RFC 1033/ 1034 / 1035.
	It had negative consequences.  It was good engineering to
	correct this.  It was also good engineering to report a
	common error to the community so that other vendors could
	fix their mistakes.
 
	Good engineers learn from their mistakes and try hard not
	to repeat them.  They also learn from the mistakes of others.
	That's why bridge designs are wind tunnel tested these days.

> Trying to "belittle" the effects with the "LOL", as opposed to offering
> anything substantive, simply suggests that you have no appreciation of the
> seriousness of the changes.  Perhaps you should take this more seriously.

	I'm quite aware of what the change requires.  I'm also aware
	that most of the nameserver are used in situations where
	the zone contents is already preserved because they are not
	serving zones with parent / child relationships.

	Anyone saying that all the nameservers need to be replaced
	immediately is spreading FUD.  LOL the the correct reponse
	to FUD.
 
	Using a server that perserves zone contents under all
	conditions doesn't break anything.

> > > > > 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 likin
> g.
> > > >
> > > > 	The constaint was already there and it is necessary for reliabl
> e
> > > > 	operation of the DNS.
> > >
> > > No, you ware not being honest about the contents of the Draft. See my las
> t
> > > 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.
> 
> I've no doubt that you fail to see it. We seem to be focusing a lot on
> your failures. I have to question whether someone who went to MIT could
> really fail so often. Perhaps it has changes since I was there. Or perhaps
> you aren't really taking this very seriously. Let me explain it:
> 
> 1) It doesn't say that it adds a completely new, incompatible zone
> transfer protocol.  New protocols should be made through a different
> process, which includes experimentation. I'm not against experimenting
> with a new protocol. Indeed, I think this idea has some merit. However, it
> can't be "end-run standardized" by a "clarification". There is a process.

	It isn't new.  All it is saying is that the contents tramitted
	out MUST be that transmitted in.  This occurs most of the time
	already.  Note BIND is not the only implementation that does
	this.  We have already had reports of 3 other implementations
	doing this.  Even the implementations that don't guarentee the
	contents do this most of the time.  It has no negative effects.

> 2) It doesn't say that it changes AXFR with respect to SIG

	It doesn't change anything wrt to SIG.  Go read RFC 2535 which
	also says that SIG records in the answer section are part of the
	zone contents and don't need special processing.
 
> 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and
> possibly others.) without going through the appropriate standards process.

	It doen't change the status of RFC 2845.
 
> 4) It doesn't say that it changes the definition of zone data to be
> public. Zone data is absolutely not "public by definition". It could very
> well be useful to tag certain RRs as non-public, and exclude them from
> zone transfers to public servers. This "clarification" precludes that.
> This is really 2 changes.

	Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers
	are restricted to secondaries.  Nowhere in RFC 1033 / 1034 / 1035
	does it say that you should restrict zone tranfers.
 
	There is a REFUSED rcode so the possibility of refusing a zone
	transfer is allowed for but the conditions underwhich this will
	be done are not specified.  This draft does not change this.

> 5) It doesn't say that it changes the security constraints on a zone
> transfer to be limited to deny or accept only.

	Effective it does.  If you transmit the zone then you MUST
	transmit its full contents unmodified (accept).  It also
	says that you are allowed to refuse zone transfers (deny).

> The list is longer, but that should be enough.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org