ietf
[Top] [All Lists]

Re: axfr-clarify's fraudulent claims of consensus

2003-02-14 21:35:12
bert hubert writes:
Much of your criticism boils down to the fact that you do not have a
zone concept and do not want to have one, where 1034 and 1035 simply
ooze with zone definitions and they are clearly part of the DNS philosophy.

It's amazing how many errors you can pack into one paragraph. Facts:

   * My software has zones. It simplifies them for the user, by taking
     advantage of the RFC 1034 database-consistency requirements.

   * The relevant difference between my software and BIND 9 is that,
     when my software sees some of the RFC-1034-violating zones allowed
     by BIND 9, it boils them down to the RFC-1034-compliant parts.

   * BIND 8 does this to some extent too. It would sound pretty stupid
     of you to claim that BIND 8 doesn't ``have a zone concept,'' don't
     you think?

   * The BIND company's ``AXFR clarifications'' try to eliminate the
     RFC 1034 database-consistency requirements, allowing data for the
     same class+name+type to vary across zones, contrary to RFC 1034,
     sections 4.2.1 and 4.2.2.

Furthermore, this zone mismanagement is only one of many problems with
axfr-clarify.

If you decided to imitate BIND 9's database format in your software,
feel free---but stop trying to force me to do the same thing. It isn't
what my users want, and it's not necessary for interoperability.

  [ removing duplicates ]
Yes, you could build sophisticated hashes & stuff

Learn to program: ``sort -u''.

As for your suggestion to shift this programming burden to the server:
You aren't thinking straight. There will be BIND 8 servers for the
foreseeable future, so you'll have to continue removing duplicates for
the foreseeable future. You'll be imposing a burden on servers without
removing it from clients. Silly.

I do like to have the ability to add TSIGs to an AXFR in the additional
section, even if that potentially breaks older remotes.

Again, you aren't thinking straight. Servers don't randomly use TSIG;
they use it _upon request_. Random use of TSIG has no benefits; it's a
pointless incompatibility, and there's no reason to allow it. (Besides,
IPSEC does a better job than TSIG.)

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago