> On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > > > Good. You found a bug in an implementation. I thought such things were > > > off-topic for this list. This bug doesn't mean that AXFR is broken. > > > Bind 8 did not have this bug, yet it has the common understanding of AXFR > . > > > > > > Let me summarize the discussion: > > > > > > Everyone agrees that AXFR specification in RFC 1034 is ambiguous. > > > > > > Some people, many associated with Bind 9 development, assert that it is > > > necessary to change AXFR to support IXFR. This assertion has been refute > d > > > on the grounds that incremental database update does not depend on AXFR, > > > since incremental database update does not depend on the underlying wire > > > protocol used to create the remote database which is to be modified by > > > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could > > > still use IXFR, so, AXFR is independent of IXFR. > > > > Nobody is saying that preserving zone content is a *wire* > > issue. It is a server behaviour issue. > > Zone definition and content is not an AXFR issue. Server administrators > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > elsewhere) AXFR merely gives the contents of the zone as has been defined > according to the boundaries and content specified by the administrator. Well BIND 9 does this. CISCO's server does this according to John. BIND 8 doesn't always. BIND 4 doesn't always. DJBDNS doesn't always. This is independent of the method used to transfer the zone to these servers or enter the zone contents on these servers. > The contents could be given to the secondary by FTP or other method. If > you mean to change the definition of zone contents, then I would say this > proposal is hugely mis-labeled. It's not changing the definition. It is preserving the definition. It's not mis-labeled. It is stating the implict assumption that AXFR transfers what is entered as the zones contents. Nothing more, nothing less. > 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. > 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 the > 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. > 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. > > > Some people, many associated with Bind 9 development, assert that AXFR 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 currently > > > 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 [,] or > are unaware of it". Agreed. Having done so, we don't want to stir the > pot. 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 an > 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. > These unnecessary constraints are a "bad thing". > > > > To prevent confusion between the two proposals, I would like to rename th > e > > > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR > > > Clarification". The term "axfr-clarify" will not be used. > > I presume agreement on the name change? No. > > --Dean > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org