The IXFR client must simply make the changes (again, by some
implementation dependent, administrator maintained method) to the zone
by
deleting RRs and adding RR's in each sequence. The original version of
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 returning
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.
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.
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.
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.
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.
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 liking.
The constaint was already there and it is necessary for reliable
operation of the DNS.
No, you ware not being honest about the contents of the Draft. See my last
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.
2) It doesn't say that it changes AXFR with respect to SIG
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.
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.
5) It doesn't say that it changes the security constraints on a zone
transfer to be limited to deny or accept only.
The list is longer, but that should be enough.