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(_dot_)Andrews(_at_)isc(_dot_)org