Re: Bind 9 AXFR Modification vs AXFR Clarification

[Mark.Andrews@isc.org]

> On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote:
> 
> > > 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.
> 
> Actually, a parent always has some control over the child. It exercises
> this control through the glue records.  When the glue records are in the
> child zone, they need to be merged.

	Which is it.  Does the parent control the contents of its zone
	or does the child?

> If a zone transfer happens while they
> are inconsistent, it is possible for some strange results to happen.
> Ordinarilly, zone transfers don't happen when they are inconsistent, since
> the inconsistency is usually short.

	It doesn't matter if they normally happen while they are
	consistant.  You have to get correct behaviour while they
	are inconsistant.  Changing zone content on SECONDARY servers
	is not correct behaviour.
 
> Any zone transfers made during the inconsistent window are corrected so
> long as the child zone is updated with correct information after the
> parent is updated.

	This is a incorrect statement.
 
> Frequently the parent and child zone are under different administrative
> control, and are frequently on different servers. In such a case, the
> contents of the parent zone aren't merged with the child in the child's
> server, and no evidence of the inconsistency is seen through zone
> transfers. However, the inconsistency still exists and may still be
> visible by resolvers and nameservers that lookup the glue records.

	Nobody is claiming that inconsistancies don't occur all the
	time.  What we are claiming is that those inconsistancies
	need to be preserved in SECONDARY servers for the correct
	operation of the DNS.  That they can only be corrected by
	modifying the PRIMARY source of the zones.
 
> You have obtained no benefits by these constraints.

	There are clear benefits in preserving zone contents on
	SECONDARY servers.
 
> > > > > 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 bein
> g
> > > > 	unilaterally changed by the servers.
> > >
> > > It is reasonable and necessary to merge in glue. When you misconfigure th
> e
> > > 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.
> 
> It is necessary, since the parent has glue records in the child zone.
> The parent therefore has (always) a part of the child zone. If that server
> also loads the child zone (or perhaps generates part of it dynamically),
> it quite reasonable to merge the records as though the zone includes
> multiple files, which in theory, it does.

	No it isn't.  Changes need to come from the PRIMARY source not
	from intermediate sources.
 
> The child zone contents will only be correct when the administrators of
> both zones agree on the contents of the glue records, and update their
> parts of the child zone accordingly. It will not be correct until then,
> regardless of how many zone transfers take place.

	Which is what I've been saying all along.  It doesn't require
	a server to "correct" the content at a intermediate point.  Such
	"corrections" actually cause problems.
 
> > 	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.
> 
> This is a loaded statement. The part of the server NOT involved in
> responding to queries and zone transfers is part of the administrative
> function. So, as part of that administrative function, it has to be able
> to modify the RR and zones accordingly.  Your proposed changes exclude a
> huge part of the potential for intelligence in name servers. And do so
> with no benefits.

	The benefits are correct operation of the DNS regardless of the
	propogation timings involved.  If servers don't modify slave zone
	content then which the master servers are brought into sync all
	the servers will be brought into sync.

	This is not guarenteed if the zone content is modified by a
	secondary server.
 
> > > > > 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.
> 
> You seem to make a case that in general, non-compliance doesn't hurt
> anything. This is false, for both technical and commercial reasons.
> Technically, it hurts interoperability, which has some many obvious harms
> I won't go into them. Commercially, implementations make and advertise
> compatibility and standards compliance claims. This retroactively makes
> those claims false, which harms the business and reputation of those other
> vendors.

	They will be harmed much more if they don't correct a common
	error now that it has been pointed out.

	The claims were made in good faith and will be accepted as
	such.
	
> 77% will need a fix from the vendor, if we were to accept these changes.
> 
> The vendor that made false claims of compatibility and standards
> compliance is Bind 9. It should suffer the commercial damage to its
> business and reputation, as a result.

	BIND 9 conforms to RFC 1034.  Nothing in RFC 1034 says to
	merge zone content.  If fact 1034 says that this a administrative
	responsability.
 
> > > Your failure to comprehend the consequences of the changes does not lesse
> n
> > > 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 hav
> e
> > > 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.
> 
> Ok, you are half way there. They are irrelevant because IXFR is
> irrelevant. These changes are not necessary to IXFR, as I explained that
> IXFR can work with the current AXFR, or even without AXFR.

	IXFR cannot work through SECONDARY servers that change zone
	content regardless of whether the content was learnt via
	AXFR or IXFR.

> > 	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.
> 
> Actually, since the parent has the glue in the child zone, it has part of
> the child zone as well as the master zone.  Merging them together is not
> prohibited, and in the case where child and parent have the same
> adminstrator, as might be the case where most of the child is simply
> automatically generated by the nameserver, can make things much easier.
> 
> Your constraints preclude this unnecessarilly.

	The constraint in on the SECONDARY server.
 
> Since I can think of cases where it is useful to merge records together,
> it is bad engineering to remove that flexibility and obtain no benefits in
> return.
> 
> > > Trying to "belittle" the effects with the "LOL", as opposed to offering
> > > anything substantive, simply suggests that you have no appreciation of th
> e
> > > 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.
> 
> Apparently, you aren't even aware that your changes will make all non-bind
> 9 servers non-compliant.  Had you been aware of that, it seems you would
> have brought this proposal forward something like 3 years ago, before
> releasing Bind 9, and before publishing a book on the subject.

	Well you obviously have not been reading.  ISC is not the
	only vendor to come to the same conclusion about preserving
	zone content.  I suspect that they are just bored with
	arguing with you and Dan.
 
> > 	Anyone saying that all the nameservers need to be replaced
> > 	immediately is spreading FUD.  LOL the the correct reponse
> > 	to FUD.
> 
> Making 77% of the servers non-compliant is a fact of your proposed
> changes.  It is another fact, as explained, that non-compliant servers
> will need to be replaced.  Will they suddenly stop working? It depends on
> whether other implementations want to implement a "backwards
> compatibility" mode. If they don't implement this mode, then the answer is
> yes, they will stop working as soon as these updates are deployed by other
> vendors. Of course, this is a bad result.

	Well they havn't stopped working in the last two years that
	this code has been out there.  Nothing in this drafts stops
	a server implementing it taking to any other server.

	There is one backwards compatiblity switch which is only
	requires if you decide to send multiple records in a single
	messages.  A server is not required to send multiple records
	in a single message.

> > 	Using a server that perserves zone contents under all
> > 	conditions doesn't break anything.
> 
> Your constraints break useful services, and offer no value in return.

	What's useful about modifing the contents of a slave zone?  All
	I can see is harm.
 
> > > 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, i
> t
> > > 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.
> 
> No, Section 3.1 is a whole new derivative of AXFR. That is new.

	Actually it's always been allowed by RFC 1034.  Just because
	it wasn't implement initially doesn't mean that it was not
	allowed.
 
> > > 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.
> 
> Oh. Then section 3.3 can be deleted in entirety without objection.
> 
> > > 3) It doesn't say that it changes the status of other RFC's (RFC 2845, an
> d
> > > possibly others.) without going through the appropriate standards process
> .
> >
> > 	It doen't change the status of RFC 2845.
> 
> The IEFT index indicates that RFC 2845 is "Proposed Standard", with no
> applicability statement that I could find.  This changes it to
> "RECOMMENDED" requirement level.  I think an applicability statement is
> premature until RFC 2845 is moved along, and then by the appropriate
> standards body decision-making process. It is inappropriate to hide
> something like this deep in an irrelevant "clarification".
>
> > > 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.
> 
> I don't think you understood my statement. I'm talking about the
> definition of zone data. Nowhere does 1034 etc say that zone data is
> public.  It may well have been thought to be public, originally, but since
> I can easily see a useful purpose in withholding some private RRs, there
> isn't any reason to preclude that behavior.

	Does this address your concerns?

   "The zone transfer protocol allows read-only access to the complete
   zone data.  When the data being served to the public it is
   generally acceptable to allow unrestricted access to it via AXFR.
   Sites that wish to avoid disclosing their full zone data MAY
   restrict zone transfer access to authorized slaves."

	If you have part of a zone to which you would normally
	return REFUSED to I suggest that you also return REFUSED
	to AXFR.

	If you want to be able to return partial zones then I suggest
	that a new TYPE be defined so that receipients can know
	that the results will be incomplete.

> Your constraints harm a useful purpose, and provide no benefits.
> > 	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.
> 
> Your modifications put additional and unnecessary restrictions on a zone
> transfer. Again, these restrictions have no useful purpose.

 
> > > 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).
> 
> This was addressed in the previous comments.
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org