> > > On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > > > All the IXFR server needs to do is determine (by some implementation > > > dependent, administrator maintained method) what has changed between one > > > zone version and another. How it does this is nobody's business but the > > > administrator and the implementor. There are infinite possibilities, here > . > > > One could, for example, store differences in a series of files. The > > > administrator could even make the differnce files by hand--this is an > > > _implementation detail_. The IXFR server just sends a series or sequences > > > consisting of a list of deleted RRs and a list of added RRs to an IXFR > > > client. There is nothing more to it. (notwithstanding the optional > > > condensation.) > > > > All of which is irrelevent to this issue. > > THAT's what I have been saying. You were the one who said we needed to do > this to support IXFR. I've been saying that claim was wrong. Thanks for > FINALLY coming round to that. > > > > 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. > > > This isn't rocket science, and doesn't require any AXFR changes. Nor does > > > it require that the zone boundaries be defined only in some certain way, > > > beyond the definition of zone boundaries given by the system > > > administrator. > > > > It does however require that for a given serial number that all > > sources of the zone have supplied identical contents. You should > > be able to apply a IXFR delta to a copy derived from any source > > and have it apply without error. > > None of this is relevant. All that is necessary is to delete the RRs, and > insert the RRs in the sequence. > > 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. > > > > > Some people, many associated with Bind 9 development, assert that AXF > R as > > > > > commonly implemented by many implementors over many years, is broken, > and > > > > > can't transfer domains correctly. This claim has been refuted by > > > > > demonstration by interoperability between Bind 8 and other nameserver > > > > > implementations over the years, and 77% of the internet that currentl > y > > > > > does not use Bind 9, yet still does AXFR. > > > > > > > > All this shows is that these nameservers are not used in > > > > situations where the breakage is demonstrated or the > > > > administators have learn to work around the breakage or > > > > choose to live with it or are unaware of it. > > > > > > "administrators have learn[ed] to work around [it,...] live with it [,] o > r > > > are unaware of it". Agreed. Having done so, we don't want to stir the > > > pot. > > > > LOL. > > 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. > > > 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. > > > > > To prevent confusion between the two proposals, I would like to renam > e th > > > e > > > > > first proposal "Bind 9 AXFR Modification", and the second proposal "A > XFR > > > > > Clarification". The term "axfr-clarify" will not be used. > > > > > > I presume agreement on the name change? > > > > No. > > Then the entire draft should be rejected since it is misleading. Please > resubmit a proposal that isn't misleading the community about its purpose, > impact, and contents. > > --Dean -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org