Re: axfr-clarify's fraudulent claims of consensus

["D. J. Bernstein" <djb@cr.yp.to>]

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