Date: 17 Nov 2002 17:45:53 -0000
Message-ID: <20021117174553.55961.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: iesg@ietf.org
Cc: namedroppers@ops.ietf.org, ietf@ietf.org
Subject: Re: DNSEXT WGLC Summary: AXFR clarify
References: <5.1.1.6.2.20021113115011.016d7490@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Gudmundsson writes:
> DNSEXT has completed it's review of this document and requests that
> it be advanced to Proposed standard.

Excuse me? When did that happen? The document is highly controversial.
The conclusion of the July meeting was ``Not ready to go: axfr-clarify,
too bind specific.'' There were no subsequent public discussions.

In fact, it's even worse than that: this so-called ``clarification'' is
specific to _BIND 9_. It imposes requirements incompatible with BIND 8,
djbdns, and probably a bunch more widely deployed servers.

http://cr.yp.to/djbdns/axfr-clarify.html gives detailed explanations of
my ten objections to this document. To summarize:

   * ``Timeline'': This document obviously does not have consensus. This
     is the fourth time that Gudmundsson has tried to ram this document
     through the process by misrepresenting the WG discussions.

   * ``AXFR client security issues'': The document ignores an essential
     security requirement for AXFR clients. This is important background
     for the next two objections.

   * ``Parent-child discrepancies'': The document allows violation of
     one of the fundamental RFC 1034 database-consistency requirements.
     It forces perfectly legitimate, widely deployed, implementations to
     change their database structures to handle those violations in the
     same way that BIND 9 does.

   * ``What is allowed in a zone?'': In response to an interoperability
     problem added to the BIND 9 AXFR client, the document attempts to
     outlaw perfectly legitimate, widely deployed, AXFR server behavior.

   * ``Records outside the answer section'': The document outlaws some
     perfectly legitimate, widely deployed, AXFR parsing techniques.

   * ``Unauthorized clients'': The document outlaws the perfectly
     legitimate, widely deployed, behavior of dropping AXFR connections
     from attackers.

   * ``Clients checking RCODE'': The document outlaws some perfectly
     legitimate, widely deployed, AXFR parsing techniques.

   * ``Clients checking IDs'': The document discourages some perfectly
     legitimate, widely deployed, AXFR parsing techniques.

   * ``Servers repeating questions'': The document discourages some
     perfectly legitimate, widely deployed, AXFR response formats.

   * ``Servers repeating records'': The document discourages some
     perfectly legitimate, widely deployed, AXFR response formats.

My web page also mentions, for completeness, two problems that were
fixed in axfr-clarify-02.

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