ietf
[Top] [All Lists]

Re: Bind 9 AXFR Modification vs AXFR Clarification

2003-02-26 15:00:59
On Fri, 21 Feb 2003 Mark(_dot_)Andrews(_at_)isc(_dot_)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. 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.

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.

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.

You have obtained no benefits by these constraints.

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.

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.

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.

      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.

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.

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.

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.

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.

      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.

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

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.

      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.

      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.

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.

No, Section 3.1 is a whole new derivative of AXFR. That is new.

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, and
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.

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.