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