[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bind 9 AXFR Modification vs AXFR Clarification
> On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote:
>
> >
> > > 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 con
> trol
> > > > 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?
>
> You seem not to understand the subtlety of the issue. The parent (like
> real parents) ultimately controls the child, but the child (like real
> children) has limited autonomy.
It is a subtle issue. You can only apply changes to the PRIMARY source
of the data. Applying changes at any other point has the potential to
cause servers to serve incorrect content.
> > > 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, sinc
> e
> > > 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.
>
> Sure it is. Unless you can arrange to conduct both updates simultaneosly.
> While it would be possible to coordinate such changes on the phone,
> relativity could come into play someday. It has nothing to do with zone
> transfers. Its part of the state of the system. Zone transfers is only one
> way to learn about the state of the system.
Changing the content of zones in SECONDARY servers prevents other SECONARY
servers using the first SECONDARY server learning the correct state of the
system.
> > > 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.
>
> Could you elaborate?
Server A master to parent.
Server B master to child.
Server C slave to parent and child.
Server D slave to parent using C as master.
All servers with NS RRset N of child zone.
Server B updates NS RRset to N'.
Server A updates NS RRset to N'.
Server C transfers parent from A.
Server D transfers parent zone from C.
Server C transfers child zone from B.
End state with modification (BIND 8/tinydns).
Server A N', Server B N', Server C N', Server D N.
End state without modificatin (BIND 9).
Server A N', Server B N', Server C N', Server D N'.
You will notice that the last transfer above was the transfer of
the child zone.
Now lets update the child last.
Server A updates NS RRset to N'.
Server B updates NS RRset to N'.
Server C transfers parent from A.
Server D transfers parent zone from C.
Server C transfers child zone from B.
End state with modification (BIND 8/tinydns).
Server A N', Server B N', Server C N', Server D N.
End state without modificatin (BIND 9).
Server A N', Server B N', Server C N', Server D N'.
You will notice that the last transfer above was the transfer of
the child zone.
Lets wait for the parent zone to propogate to all servers
before updating the child zone.
Server A updates NS RRset to N'.
Server C transfers parent from A.
Server D transfers parent zone from C.
Server B updates NS RRset to N'.
Server C transfers child zone from B.
End state with modification (BIND 8/tinydns).
Server A N', Server B N', Server C N', Server D N.
End state without modificatin (BIND 9).
Server A N', Server B N', Server C N', Server D N'.
Now if you force everyone to wait until the child zone
has progated.
Server B updates NS RRset to N'.
Server C transfers child zone from B.
Server A updates NS RRset to N'.
Server C transfers parent from A.
Server D transfers parent zone from C.
End state with modification (BIND 8/tinydns).
Server A N', Server B N', Server C N', Server D N'.
End state without modificatin (BIND 9).
Server A N', Server B N', Server C N', Server D N'.
You will notice that in all examples BIND 9 ends in the correct
state. The same cannot be said for BIND 8 or tinydns.
Modification of SECONDARY zone content is NOT required or desirable
for the correct operation of the DNS.
> > > 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.
>
> ??? I can't parse this with respect to your previous statements. Could
> you rephrase it?
You make changes at the PRIMARY server for the zone.
You do not make changes to zones anywhere else.
> During the period in which the zone is inconsistent, there is no guarantee
> the zone will work. Depending on the nature of the change, wrong
> information may be given in queries as well. Suppose the parent is
> removing control from the child, and has updated the glue to remove
> referals to the child nameservers. For some time (the TTL, at least), the
> original child servers will be queried.
What does this have to do with this draft?
> On the other hand, the child zone may not even exist yet on the childs
> nameservers. Referals to the zone fail.
What does that have to do with this draft?
> To make a concrete example, Osama registers alquaeda.com, and begins
> coordinating his evil deeds. The registrar delegates the alquaeda.com as a
> child of .com. Eventually, the government intervenes, and .com replaces
> Osamas nameserver glue with new glue pointing to government servers. For a
> time, this zone will be inconsistent. Note that in this case, the zone
> transfers will not indicate the inconsistency. However, for a short time,
> Osama will be able to put up a message warning his followers not to go to
> the government run site. This can't be avoided, no matter what gyrations
> you put AXFR through.
What has this got to do with this draft?
> It makes no difference that the inconsistency _could_, _in_some_cases_, be
> seen at the secondaries.
It does make a difference as demonstated above.
> > > You have obtained no benefits by these constraints.
> >
> > There are clear benefits in preserving zone contents on
> > SECONDARY servers.
>
> Such as?
>
> Your term "preserving zone contents" is misleading. The zone contents are
> not corrupted. The glue is inconsistent. What is the benefit of
> preventing any trace of inconsistency in the secondary?
It may be inconsistant but which version is correct? The copy
in the child may be out of date.
> It has nothing to do with IXFR. It has nothing to do with anything.
IXFR still requires the content to only be changed in response
to IXFR deltas.
> > > 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 serve
> r
> > > 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 intermediate sources aren't making changes. They are, at worst,
> propogating old information mixed with new information. However, this is
> visible in other ways besides zone transfers.
You are changing the contents if you mix data from different zones.
> > > 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.
>
> Good. Then you agree that Bind 8 behavior is correct.
BIND 8 "corrects" data at intermediate points. BIND 9 doesn't.
BIND 8's behaviour is wrong.
> > > > Nothing in RFC 1033 / 1034 / 1035 says that a server is permitt
> ed
> > > > to alter the content of a zone. The responability for maintain
> ing
> > > > 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.
>
> We already have correct operation of DNS. The zone contents are
> inconsistent until both adminstrators come to agreement. The child zone
> should be updated last. After the child zone is brought into agreement
> with the parent glue, zone transfers will be made which are correct. Only
> then will zone transfers will be correct. Zone transfers made while the
> administrators are not in agreement will not be correct, even if there is
> no apparent evidence in the zone data from the child (such as a mixture of
> new and old glue) they are still incorrect. NS Queries against the parent
> and child servers will return different results.
What have you been smoking?
> > 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 the
> re.
> > > > > >
> > > > > > You really think that it will break those servers? LOL.
> > > > >
> > > > > They will not be compliant, and thus will need to be changed. Thus, t
> hey
> > > > > 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 othe
> r
> > > vendors.
> >
> > They will be harmed much more if they don't correct a common
> > error now that it has been pointed out.
>
> Except, there are no errors, beyond a window of inconsistency that cannot
> be avoided, and in fact, that window isn't fixed. Nor do you fix the
> "error". They are _still_ inconsistent for a period. And the child will
> _still_ have to be updated last.
You obviously don't understand the problem
> > The claims were made in good faith and will be accepted as
> > such.
>
> I'm not convinced. If they were, we would have argued this before Bind 9
> was released, and before a book was sent out. Probably about 3 years ago.
> Someone knew years ago when they wrote the "backward compatibility" mode,
> that they had a protocol issue that would have to come before
> namedroppers. That they delayed for so long doesn't indicate good faith
> to me.
We having been saying for years before BIND 9 was released that
that BIND 8 had this wrong. BIND 9 conforms to RFC 1034.
Axfr-clarify arose because it was pointed out that IXFR depended
upon the definition of AXFR and that AXFR was not well specified.
> > > 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.
>
> It does right now, due to a knowingly reckless exploitation of ambiguity
> in the AXFR. Once AXFR is clarified, Bind 9 will have to use its 'backward
> compatibility' mode to be compliant.
What "reckless" exploitation?
> It is "knowingly reckless" because the Bind 9 implementers _KNEW_ they
> needed to provide a "backward compatibility". That means they knew what
> they were doing was incompatible with any (all actually) reasonable
> interpretation (however ambiguous) of 1034.
The only thing that requires a backward compatability switch
is sending multiple records in a message.
BIND 4 accepted these back in 1996. Other vendors started
accepting these back in 1996. BIND 8 has always accepted
them and could be configured to send them. BIND 9 defaults
to sending them and can be configured not to.
At the same time as this was happening other vendors also
started sending them. We all knew that there was interoprability
issues that were a result of oversites in the implementation.
One vendor even made use of the fact that named (and I
presume other servers) didn't barf on a oversized query to
signal to it servers that they could send a multi-record
respones.
> > > > > Your failure to comprehend the consequences of the changes does not l
> esse
> > > n
> > > > > the effect. We now agree that these changes aren't necessary to supp
> ort
> > > > > IXFR. You were part of the bad engineering that led to the unnecessar
> y
> > > > > 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 t
> he
> > > > > 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.
>
> Sure it can. It doesn't need AXFR at all. And the secondary's aren't
> making arbitrary changes at all.
If servers wern't making arbitary changes we would not be having
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.
> > >
> > > 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.
>
> So? It is still unnecesary.
Next you will tell me that the grass is blue and the sky is green.
If you can't see the need for the constraint stop blocking those
that do.
> > > 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 i
> n
> > > return.
> > >
> > > > > Trying to "belittle" the effects with the "LOL", as opposed to offeri
> ng
> > > > > anything substantive, simply suggests that you have no appreciation o
> f th
> > > e
> > > > > seriousness of the changes. Perhaps you should take this more seriou
> sly.
> > > >
> > > > 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-bin
> d
> > > 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.
>
> I think they just haven't really read the proposal's, and have taken some
> misleading assurances at face value.
>
> > > > 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 i
> s
> > > yes, they will stop working as soon as these updates are deployed by othe
> r
> > > 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.
>
> Uhh, wrong. The drafts make the current AXFR non-compliant. There is
> nothing that would require a server to implement the old AXFR and provide
> a "backwards compatibility" mode such as Bind 9 has.
So you want
"Slaves MUST accept messages containing any number of answer RRs. For
compatibility with old slaves, masters that support sending multiple
answers per message SHOULD be configurable to revert to the
historical mode of one answer per message, and the configuration
SHOULD be settable on a per-slave basis."
replaced with
"Slaves MUST accept messages containing any number of answer RRs. For
compatibility with old slaves, masters that support sending multiple
answers per message MUST be configurable to revert to the
historical mode of one answer per message, and the configuration
SHOULD be settable on a per-slave basis."
> So servers running today, won't be able to talk to strictly compliant
> servers that don't have a backwards compatibility mode.
> > 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.
>
> But is allowed to, and a server that can't receive such messages won't be
> able to get the zone.
>
> > > > > 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 experimentin
> g
> > > > > with a new protocol. Indeed, I think this idea has some merit. Howeve
> r, i
> > > t
> > > > > can't be "end-run standardized" by a "clarification". There is a proc
> ess.
> > > >
> > > > 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.
>
> Uhh, wrong, except in an unreasonably broad technical exception due to the
> vagueness of 1034.
Multiple records in the answer section have always been part
of the standard.
> > > > > 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 fro
> m
> > > > > 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 transfe
> rs
> > > > are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 10
> 35
> > > > 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 sinc
> e
> > > 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?
>
> No. Because it might be reasonable not to give complete zone data.
>
> > "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.
>
> So far as the secondary is concerned, the zone is complete. If you do
> this, you don't want to tell people that you have some data that isn't
> public. Nor would you ever need to.
Well if you don't want to tell them that you have private
part then you won't be answering with REFUSED. You effectively
have two zones that just have a lot in common. Treat them
as such.
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org