Subject: Re: Poison in a zone

From: Dean Anderson <[email-masked]>
Date: Tue, 25 Feb 2003 14:49:06 -0500 (EST)

Dan, Kanda: Do you support the clarification with these changes:

I'll write up the draft with these changes, if you agree.

++++++++++ repost from last week

The second paragraph of Section 2 should be deleted.  Specific
implementations are not to be mentioned in RFC's.

In section 3, where it says "MUST" it should say "MAY", and where it says
"MAY", it should say "MUST".

Section 3.1 seems like a good idea, however, it is a modification to AXFR,
and should have a new request code. I suggest calling it MAXFR and giving
it code 253.  Support for this request code should be optional, and a
server may respond using the original (one record per message) AXFR
method. Upon discovering non-implemenation, clients should fall back to
AXFR or fail as determined by implementation or configuration.

Section 3.3 should be deleted. This is up to the administator and/or the
implementation.  SIG processing is not addressed, neither by when the
server should put them in, nor by what the client should do with them if
present.

Section 3.4 should be deleted.

Section 3.5 and 3.6 should be deleted. Data can come in either authority
or additional sections.  There are no transaction signatures, except for
id, question, and serial number.

Section 4 should be deleted.  Clearly, glue records need to be merged in.

Section 5 paragraph 3 should be deleted except for the first sentence.
In the forth paragraph, where it says "MUST", should say "MAY".
Clearly, duplicate records may indicate a misconfiguration, and their
presence in a zone can indicate a problem. Or not. It is up to the
administrators to determine how they configure there servers, and to
configure those servers consistently.

Section 6 should be deleted.  The status of these other RFCs is not to be
altered except by appropriate standardization process.  This is an
inappropriate end-run around that process.

Whether zone data is public is an administrative decision not limited by
RFC. Administrators are free to place or implement whatever restrictions
they wish on domain name records, and such administrative restrictions are
not limited to only zone transfer restriction. They can, for example, be
limited by node or record type, or any other way that can be invented and
found useful.
++++++++++++++++++++++++++++++++++

		--Dean

On 25 Feb 2003, D. J. Bernstein wrote:

> Kandra Nygards writes:
> > May I assume that you're supporting the AXFR-clarify draft as long as
> > the above clarification is made?
>
> Of course not.
>
> The existing draft is inconsistent with RFC 1034, inconsistent with most
> of the installed base, and---as Gustafsson now admits---inconsistent
> with BIND 9. Your additional ``clarification'' doesn't change this; it
> simply highlights BIND 9's failure to follow the rules.
>
> Furthermore, even if the wacko zone-coherency requirements are dropped,
> axfr-clarify will still need to be fixed in several other ways.
>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Feb 2003 22:44:16 -0000

> I'll write up the draft with these changes, if you agree.

The existing draft was shoved into Last Call with huge problems. I'm
still waiting for it to be withdrawn (or rejected).

There are obviously bigger problems here than clarification of the AXFR
protocol. The discussion has revealed a huge gap between

   * RFC 1034, which simplifies software but demands that administrators
     maintain exact glue consistency, and

   * the ``zone coherency'' cult, which removes some administrative
     requirements (but not all) while demanding that AXFR clients (but
     not other clients) maintain exact copies of zones no matter how
     inconsistent those zones are---a rule that even BIND 9 violates.

The real world is somewhere between these extremes. Perhaps we can have
a rational cost-benefit discussion, now that BIND 9's disobedience of
the cult has been exposed.

Meanwhile, http://cr.yp.to/djbdns/axfr-notes.html covers several issues
that aren't covered in axfr-clarify.