ietf
[Top] [All Lists]

Re: Bind 9 AXFR Modification vs AXFR Clarification

2003-02-19 17:02:24



On Wed, 19 Feb 2003 Mark(_dot_)Andrews(_at_)isc(_dot_)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(_dot_)Andrews(_at_)isc(_dot_)org