Dean Anderson writes:
> I don't think they can be dismissed so easilly. Indeed, I think the
> proposed changes are rather "oddball", and are actually unncessary in
> order to implement IXFR (which was the original claimed justification).
This is not a "change". There are no existing standards which mandate
or even explicitly allow mixing of data between zones. On the
contrary, RFC1035 specifically suggests using separate data structures
that ensure that no such mixing occurs:
6.1.2. Database
While name server implementations are free to use any internal data
structures they choose, the suggested structure consists of three major
parts:
- A "catalog" data structure which lists the zones available to
this server, and a "pointer" to the zone data structure. The
main purpose of this structure is to find the nearest ancestor
zone, if any, for arriving standard queries.
- Separate data structures for each of the zones held by the
name server.
- A data structure for cached data. (or perhaps separate caches
for different classes)
Which one is more "oddball", a server which follows this suggestion or
one which does not?
> Indeed, the proposed changes are only necessary to justify BINDs' oddball
> IXFR changes. They are only necessary to make BIND 9 compliant with the
> RFC's.
BIND 9 is compliant with the existing AXFR standard even without
axfr-clarify. It's not hard to comply since the existing the
specification is almost nonexistent.
> It seems quite odd that a "clarification" would put 77% of the existing
> servers out of compliance,
77% of the existing servers do not reliably interoperate in IXFR (even
with one another), and sometimes serve data inconsistent between the
authoritative servers of a zone. They *should* be declared out of
compliance.
> and only brings into compliance a currently
> non-compliant implementation.
Again, BIND 9 is currently compliant.
> Consensus on the part of Bind proponents, yes. Consensus when the wider
> community is counted, no.
I am not a BIND proponent. Although I wrote the draft while working
on BIND 9, I encountered the interoperability problems caused by the
current lack of specification and saw the need for clarification years
before I received my first BIND-related paycheck. I currently work on
products that directly compete with BIND, and I have no financial
incentive to see BIND succeed.
I have been reluctant to bring up this issue because because it should
make no difference whatsoever - the draft should be judged solely on
its technical merits, not based on the affiliations of its proponents,
but the groundless accusations of misconduct and conspiracy theories
by you and Dr. Bernstein have gone too far.
--
Andreas Gustafsson, gson@nominum.com