Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 02 Jul 2001 11:42:08 -0700

D. J. Bernstein writes:
> I have glanced at the summary of changes provided in the last call. It
> seems that several of my objections have been ignored.

They were not ignored.  They were considered and rejected.
-- 
Andreas Gustafsson, [email-masked]

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Olafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Mon, 02 Jul 2001 13:15:06 -0700

At 10:17 PM 6/30/2001, D. J. Bernstein wrote:
>Where did the WG chairs get this ``SHORT last call'' idea from?
>
>This draft was announced on 22 June. The WG chairs, without giving us
>any extra time to review the draft, announced a ``SHORT last call''
>ending on 30 June.
>
>I've just returned from vacation. I haven't seen the draft yet. I object
>to this absurd last-call schedule.

so you want more time, you got through the 6'th.

         Olafur

---

From: "D. J. Bernstein" <[email-masked]>
Date: Tue, 03 Jul 2001 22:43:03 -0700

> so you want more time, you got through the 6'th.

I have set up a web page, http://cr.yp.to/djbdns/axfr-clarify.html,
stating my objections.

I'd like to emphasize that the axfr-clarify draft repeatedly violates
RFC 2119, section 6, by trying to ``impose a particular method on
implementors where the method is not required for interoperability.''

---Dan

---

From: Olafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 04 Jul 2001 10:49:31 -0700

>I have set up a web page, http://cr.yp.to/djbdns/axfr-clarify.html,

Unless it is posted on the mailing list, or sent to chairs&author(s)
working group can not consider this material as part of it.
Web pages are not acceptable input.

>implementors where the method is not required for interoperability.''

you are really twisting RFC2119 section 6, by selective quoting. The
section is a warning about the over use of the word MUST not a restriction
on what can be specified.
The document in question here is specifying "If an implementation does
optional protocol element AXFR then do it like this".

If your implementation is not compliant then you have three choices,
         1. Convince the working group to change the specification
         2. Update your incorrect implementation
         3. Discontinue distribution of non compliant software.

We will have an interoperabilty test for AXFR at some time in the not to
distant future and you are strongly encouraged to participate.

Q: did you write your implementation of AXFR before or after version 00
of the draft was published in March last year.
         Olafur

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 04 Jul 2001 11:09:39 -0700

Apparently the DNSEXT chair doesn't have web access, so here's the
output of lynx -dump http://cr.yp.to/djbdns/axfr-clarify.html.

---Dan

   [1]D. J. Bernstein
   [2]Internet publication
   [3]djbdns
   
                  The BIND company's ``AXFR clarifications''
                                       
   * means BIND company employee or owner.
   
Timeline

   2000-03-03: Andreas Gustafsson* released axfr-clarify-00, a ``DNS Zone
   Transfer Protocol Clarifications'' document.
   
   2000-07-18: Gustafsson* released a new draft, axfr-clarify-01. There
   was some discussion on the [4]censored DNSEXT mailing list: 2 messages
   from DNSEXT censor Randy Bush, 4 from Gustafsson*, 3 from Eric Hall, 2
   from Peter Koch, 4 from Josh Littlefield, and 1 from Paul Vixie*.
   
   ``The purpose of this draft is not to change the protocol but to
   document it in its existing form,'' Gustafsson* said.
   
   2001-03-13: Olafur Gudmundsson issued a DNSEXT last call to put
   axfr-clarify-01 on the standards track. ``The document formalizes the
   zone transfer protocol in accordance with the fielded DNS server
   software,'' he said.
   
   I raised several serious objections, and explained them in detail, in
   a series of 9 messages. One of my messages was [5]discarded by the
   DNSEXT censor. The discussion included 2 messages from Mark Andrews*,
   2 from Kevin Darcy, 1 from Aaron Durchgaloch, 3 from Gustafsson*, 1
   from Koch, 3 from Masataka Ohta, and 2 from Brian Wellington*.
   
   2001-04-04: Several messages from me, a few from Gudmundsson, 4 from
   Andrews*, 1 from Roy Arends*, 4 from Darcy, 1 from Robert Elz, 1 from
   Gustafsson*, 2 from Greg Hudson, 1 from Bill Sommerfeld, 4 from
   independent DNS implementor Sam Trenholme, and 1 from Wellington*.
   
   The discussion began when Olafur Gudmundsson claimed that ``the
   working group consensus is to advance the document'' once certain
   minor issues had been addressed. Gudmundsson never provided any
   justification for this claim.
   
   Trenholme blasted Gudmundsson on another mailing list:
   
     The process for making DNS-related RFCs is open only in name. In
     reality, the people in the process of making DNS-releated RFCs are
     not listening to a number of important objections. For example,
     there was a recently proposed RFC which adds a bunch of arbitrary
     and, quite frankly, useless, rules to the AXFR (zone transfer)
     process.
     
     Dan, rightly so, brought up a number of objections with this
     internet draft.
     
     These objections were completely ignored.
     
   2001-06-22: Gustafsson* released a new draft, axfr-clarify-02, with
   several ``major changes.'' Gudmundsson immediately issued a ``SHORT
   last call,'' with a deadline of 2001-06-30.
   
   Discussion over the next week included 3 messages from Darcy, 5 from
   Elz, 7 from Gustafsson*, 1 from Gudmundsson, 1 from Hall, 1 from Koch,
   2 from Littlefield, and 4 from Vixie*.
   
   2001-06-30: I returned from vacation. I immediately objected to
   Gudmundsson's absurd last-call schedule; Gudmundsson extended the
   deadline to 2001-07-06. I again pointed out that several of my
   objections had been ignored. ``They were not ignored,'' Gustafsson*
   said. ``They were considered and rejected.'' I began working on this
   web page.
   
AXFR client security issues

   Suppose I'm an AXFR client transferring the princeton.edu zone. I will
   discard aol.com information from the princeton.edu servers. This is
   required for security: the princeton.edu servers aren't authorized to
   provide aol.com information.
   
   Gustafsson* claims that aol.com glue from the princeton.edu AXFR
   servers may safely be used in referrals below princeton.edu. This
   claim is false. Suppose, for example, I also happen to be a .com
   server, and I receive the records
     blah.princeton.edu NS dns-01.ns.aol.com
     dns-01.ns.aol.com A 128.112.136.10

   from the princeton.edu AXFR servers. It is essential for me to discard
   the glue A record; otherwise I will poison caches, because caches
   trust dns-01.ns.aol.com information from .com servers.
   
Parent-child discrepancies

   Suppose I'm an AXFR client transferring both princeton.edu and
   cs.princeton.edu. I will discard all princeton.edu AXFR results below
   cs.princeton.edu, in favor of the cs.princeton.edu results.
   
   To the extent that there's a difference, the princeton.edu servers are
   wrong. For example, the princeton.edu servers say
     cs.princeton.edu NS cs.princeton.edu
     cs.princeton.edu NS engram.cs.princeton.edu

   while the cs.princeton.edu servers say
     cs.princeton.edu NS dns1.cs.princeton.edu
     cs.princeton.edu NS dns2.cs.princeton.edu

   If someone asks me for the cs.princeton.edu NS records, I'm going to
   report dns1 and dns2, not engram.
   
   Note that, when I transfer princeton.edu, I have not yet decided to
   discard the cs.princeton.edu records from the princeton.edu servers; I
   don't know at that point whether I'm also transferring
   cs.princeton.edu. Records are discarded when the transfers are
   combined.
   
   Gustafsson* and Ohta claim that records are zone-specific: in
   particular, that the cs.princeton.edu NS engram.cs.princeton.edu
   record is a valid part of the princeton.edu zone. This is not
   consistent with the DNS specifications. Here's what RFC 1034 actually
   says:
     * DNS is divided into zones. Names are partitioned among zones. Each
       zone is authoritative for all records under its names. See RFC
       1034, section 4.1.
     * Zones may, and sometimes must, contain records for which they
       aren't authoritative, i.e., records from other zones. These
       records are supposed to be exact copies of the authoritative
       records. See RFC 1034, section 4.2.1, last paragraph on page 20.
       
   When an administrator fails to correctly copy records, such as the
   cs.princeton.edu NS records, he is violating the protocol. He has no
   right to expect clients to preserve both sets of records. Clients can
   and do assume the accuracy of any record set received from any server
   authorized to provide that set.
   
   axfr-clarify-02 says that an AXFR client ``MUST associate the RRs
   received in a zone transfer with the specific zone being transferred,
   and maintain that association for purposes of acting as a master in
   outgoing transfers.'' I object to this requirement, because (1) it is
   not necessary for interoperability and (2) it prohibits the behavior
   of my AXFR client, which discards records as described above when it
   is scripted in the usual way. This requirement violates RFC 2119,
   section 6.
   
   The IETF-50 DNSEXT meeting minutes said that there was ``more
   support'' for BIND 9's ``preservation of zone content'' than for the
   BIND 8 AXFR behavior. The minutes didn't say exactly how much support
   there was, or how many people attended, or how packed the room was
   with people having financial interests in BIND.
   
   Gustafsson* says that the IXFR protocol breaks if AXFR clients discard
   bad records. Well, that's too bad for the IXFR protocol. IXFR has an
   official status of Elective, and my users have a better protocol
   (rsync), so I am not going to support IXFR, and I object to the notion
   of IXFR-induced complications in the AXFR protocol.
   
What is allowed in a zone?

   My DNS server reads all records from a single file; the system
   administrator doesn't have to worry about zones. My AXFR server
   defines the princeton.edu zone as the SOA record at princeton.edu and
   all available non-SOA records within princeton.edu.
   
   In particular, if the file includes an address for
   www.cs.princeton.edu, my AXFR server includes that address in the
   princeton.edu zone.
   
   This works just fine with my AXFR client and with the BIND 8 AXFR
   client. The client discards undesired records, as explained above; so
   the server doesn't have to.
   
   Unfortunately, the BIND 9 AXFR client rejects the entire zone transfer
   if it doesn't see www.cs.princeton.edu in an authoritative NS record
   inside the princeton.edu zone. This is a current interoperability
   problem.
   
   RFC 1034 and RFC 1035 don't prohibit zones of this type. The obvious
   fix for the interoperability problem is for BIND 9 to stop going out
   of its way to check the NS records.
   
   I could change my AXFR server to work around this BIND 9 bug. However,
   that would not be sensible engineering: it would take extra code,
   extra CPU time, and extra disk I/O.
   
   axfr-clarify-01 prohibits records ``from the authoritative data of
   zones other than the one being transferred.'' This is nonsense: every
   record is part of the authoritative data of some zone. See RFC 1034,
   section 4.2.
   
   axfr-clarify-02 prohibits records ``associated with zones other than
   the one being transferred.'' A record ``is associated with a zone by
   being loaded from the master file of that zone at the primary master
   server, or by some other, equivalent method for configuring zone
   data.''
   
   This is horribly unclear. Is Gustafsson trying to prohibit the whole
   concept of a single DNS configuration file? I object to the use of
   BIND-specific notions here; all requirements should be defined in
   terms of on-the-wire behavior.
   
Records outside the answer section

   axfr-clarify-02 says ``Slaves MUST ignore any authority section
   contents [and] any unexpected RRs in the additional section.''
   
   I object to this requirement, because (1) it is not necessary for
   interoperability and (2) it prohibits the behavior of my AXFR client,
   which takes records from all sections. This requirement violates RFC
   2119, section 6.
   
   Everyone agrees that records must never appear outside the answer
   section. If the server puts records outside the answer section, the
   server is violating the protocol. (There was consensus on this in a
   face-to-face meeting, and there has been no dispute on the mailing
   list.) This does not mean that the client is violating the protocol.
   
Unauthorized clients

   axfr-clarify-02 says ``If the master server is unable or unwilling to
   provide a zone transfer, it MUST respond with a single DNS message
   containing an appropriate RCODE other than NOERROR.''
   
   I object to this requirement, because (1) it is not necessary for
   interoperability and (2) it prohibits the behavior of my AXFR server,
   which simply closes the connection. This requirement violates RFC
   2119, section 6.
   
   AXFR is a local matter between a master and its authorized slaves.
   Clients without authorization have no business asking for AXFR.
   
   Andrews* claims that clients cannot pipeline AXFRs on a single
   connection if servers are allowed to close connections. This claim is
   false. It is easy to construct a pipelining client that will handle
   errors properly. (In the real world, client implementors open separate
   TCP connections for separate transfers.)
   
Clients checking RCODE

   axfr-clarify-02 says that an AXFR client ``MUST check the RCODE in
   each message and abort the transfer if it is not NOERROR.''
   
   I object to this requirement, because (1) it is not necessary for
   interoperability and (2) it prohibits the behavior of my AXFR client,
   which uses a different method to check for errors. This requirement
   violates RFC 2119, section 6.
   
Clients checking IDs

   axfr-clarify-02 says that an AXFR client ``SHOULD check the ID of the
   first message received and abort the transfer if it does not match the
   ID of the request.''
   
   I object to this recommendation, because (1) it is not necessary for
   interoperability and (2) it discourages the behavior of my AXFR
   client, which doesn't bother checking the IDs. This recommendation
   violates RFC 2119, section 6.
   
   ``Failing to check the ID opens a server to spoofing,'' Wellington*
   claims. That's not true. TCP connections already have sequence
   numbers, and anyone who wants serious security for AXFR can run AXFR
   over IPSEC or ssh. IPSEC-protected AXFR shouldn't bother with TSIG, so
   why should it bother checking IDs?
   
   Andrews* points out that AXFR requests can, in theory, be multiplexed
   over a single TCP connection. I agree that a hypothetical multiplexing
   AXFR client would have to check IDs. But this has no relevance to the
   behavior of my AXFR client.
   
Servers repeating questions

   axfr-clarify-02 says that ``The initial message of a zone transfer
   response SHOULD have a question section identical to that in the
   request.''
   
   I object to this recommendation, because (1) it is not necessary for
   interoperability and (2) it discourages the behavior of my AXFR
   server, which doesn't bother repeating the question.
   
   Wellington* claims that this recommendation is ``an arbitrary decision
   based on existing practice.'' In fact, it is a pointless
   recommendation that does not take full account of existing practice.
   
TSIG

   axfr-clarify-01 says that TSIG is ``RECOMMENDED.''
   
   I objected to this recommendation. People protecting their
   communications with IPSEC, for example, should not be encouraged to
   use TSIG.
   
   This problem was fixed in axfr-clarify-02, which recommends ``a
   cryptographic mechanism for ensuring authenticity and integrity,''
   such as TSIG or IPSEC or TLS.
   
Servers setting RD

   axfr-clarify-01 says that RD in a zone-transfer response is copied
   from the request.
   
   I objected to this requirement, because (1) it is not necessary for
   interoperability and (2) it prohibits the behavior of my AXFR server,
   which always sets RD to 0. This requirement violates RFC 2119, section
   6.
   
   This problem was fixed in axfr-clarify-02.
   
   I also proposed that RD be prohibited in AXFR requests. RD makes no
   sense for AXFR and is not used by existing AXFR clients. This proposal
   was ignored.
   
Servers repeating records

   axfr-clarify-02 says that, aside from the repeated SOA, each record
   ``MUST be transmitted exactly once.''
   
   This is how my AXFR server works, and it is how BIND 9 works. It is,
   however, completely out of whack with how most versions of BIND work.
   I object to this document being fraudulently characterized as a
   ``clarification,'' a codification of ``existing practice,'' and a
   description of ``the fielded DNS server software''; it should be
   labelled and reviewed as a revision of the protocol.

References

   1. http://cr.yp.to/djb.html
   2. http://cr.yp.to/web.html
   3. http://cr.yp.to/djbdns.html
   4. http://cr.yp.to/djbdns/namedroppers.html
   5. http://cr.yp.to/djbdns/namedroppers.html#2001-03-17

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 04 Jul 2001 11:59:15 -0700

>          3. Discontinue distribution of non compliant software.

You forgot one:

           4. Continue distribution of noncompliant software

(this shall be henceforth be known as the Scorched Earth approach.)

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jul 2001 12:33:34 -0700

>            4. Continue distribution of noncompliant software

and the 5th, changing the definition of compliance mid-stream

this shall henceforth be known as ...  [ i will resist ]

randy

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 04 Jul 2001 12:32:05 -0700

Olafur Gudmundsson/DNSEXT co-chair writes:
> you are really twisting RFC2119 section 6, by selective quoting.

Here's RFC 2119 section 6:

   Imperatives of the type defined in this memo must be used with care
   and sparingly. In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions) For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for interoperability.

axfr-clarify repeatedly violates these requirements. For example, it
says that implementors MUST use a particular method of extracting
records from an AXFR response packet, even though that method is not
required for interoperability.

> The section is a warning about the over use of the word MUST not a
> restriction on what can be specified.

False. The section is a blanket prohibition on certain types of
requirements and recommendations. It isn't limited to the word MUST; it
applies to all ``imperatives of the type defined in this memo.''

Why are you trying to weasel out of this? Why are you trying to force me
to change djbdns in ways that aren't required for interoperability?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 04 Jul 2001 13:12:17 -0700

[ ok, boys and girls.  can we get to technical substance please.  this is
  the last i want to approve of the pissing contest until after the
  technical discussion on the last call completes.  if it ever starts -- rb]

> of the draft was published in March last year.

I published my AXFR client and AXFR server in January 2000.

> 3. Discontinue distribution of non compliant software.

Is your rhetoric supposed to have some relevance to the facts?

My implementation works just fine. If _you_ want to change the IETF DNS
specifications then _you_ have to convince the working group.

You've been issuing absurd last calls, making unjustified claims of
consensus, and otherwise abusing your power to push this biased vendor
document out the door. I don't know what connection you have to the BIND
company, but I'm willing to bet that your actions as DNSEXT chair have
been influenced by communications that the rest of us haven't seen; I
demand that you disclose the contents of those communications.

> Web pages are not acceptable input.

Wow. Where do you get these ideas from?

Are you trying to make sure that everyone has access to the input? If
so, why is it enough to send input ``to chairs&author(s)''? Why don't
the rest of us get to see the input? And why are DNSEXT activities being
carried out on a censored mailing list where some input never appears?

Or are you saying that all input should be permanently available in the
mailing-list archives? If so, how do you explain I-Ds? I-Ds rarely
appear in the archives; we download them from temporary IETF web pages.

Perhaps more importantly, where do you get the idea that it's up to you,
rather than the working group, to decide what input is acceptable?

---Dan

---

From: Alan Barrett <[email-masked]>
Date: Thu, 05 Jul 2001 03:32:48 -0700

On Wed, 4 Jul 2001, D. J. Bernstein wrote:
> Why are you trying to weasel out of this? Why are you trying
> to force me to change djbdns in ways that aren't required for
> interoperability?

I would say that ignoring non-answer fields in AXFR, as described in
axfr-clarify, is required for interoperability with potential future
extensions to the protocol.

Thinking about extensibility is an important part of protocol
design.  IETF protocols include many examples of such forethought,
often in the form of fields reserved for future use with language
like "MUST be zero when transmitted, MUST be ignored when received".
Interoperability with future extensions is harmed when the sender
fails to zero such fields, and is also harmed when the receiver
fails to ignore such fields.

It's perfectly appropriate to use "MUST" or "MUST NOT" when
specifying behaviour that is expected to enable or interfere with
future extensibility.

--apb (Alan Barrett)

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 05 Jul 2001 10:46:34 -0700

Alan Barrett writes:
> extensibility

We aren't talking about a new protocol. We're talking about a protocol
that is already widely deployed. Section-based extensibility is not part
of the existing protocol.

I have updated my web page, http://cr.yp.to/djbdns/axfr-clarify.html, to
cover this topic:

   RFC 1034 does not say ``clients read only the answer section.'' It
   also does not say ``clients read the entire packet.'' Both methods
   work correctly.

   Andrews* says that he might want to extend the zone-transfer protocol
   by putting new information into the authority section and the answer
   section. He admits that this extension would be incompatible with my
   AXFR client, which is deployed at thousands of sites. Does he draw the
   obvious conclusion that the incompatible protocol should be deployed
   on a different TCP port? No! He demands that my users and I go to
   extra effort so that he can run an incompatible protocol on the same
   port.

   Yes, extensibility is often a helpful protocol feature, but it is
   fifteen years too late to start adding new forms of extensibility to
   the AXFR protocol. We have an installed base now, and the BIND company
   does not have the right to break compatibility with the installed
   base, even if it drops the pretense that it is merely ``clarifying''
   the existing protocol.

---Dan

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 05 Jul 2001 12:14:09 -0700

> of the existing protocol.

Section-based extensibility *is* part of the protocol, based on the evidence
of things like TSIG, SIG(0) and EDNS0, any of which could be used in an
AXFR response. Where have you been the last few years? If your client croaks
on unexpected RR's in Authority or Additional of an AXFR response, it's
broken. The clarify-draft just makes it official.

- Kevin

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 05 Jul 2001 20:48:55 -0700

>    trust dns-01.ns.aol.com information from .com servers.

No.  What is essential is that the server does not send the
dns-01.ns.aol.com glue as part of referrals out of any zone other 
than princeton.edu.

>    authorized to provide that set.

RFC1034 says the records in the parent "should" (not "must") be
exactly the same as those in the child.  This is an operational
recommendation, not a protocol requirement, and in practice,
discrepancies are extremely common and must be dealt with by the
protocol.

>    is scripted in the usual way. This requirement violates RFC 2119,

The requirement is necessary for interoperability of downstream IXFR
servers.

>    www.cs.princeton.edu, my AXFR server includes that address in the

If your server is the primary master for princeton.edu, it can of
course define the princeton.edu zone any way it likes, including the
way you described.  However, if it is a slave, it should respect the
intent of the master administrator and not insert records that were
not present on the primary master.

>    inside the princeton.edu zone. This is a current interoperability

I have no idea what you are talking about here.  The draft does not
specify that such a transfer should be rejected, and as far as I know,
BIND 9 will accept it with no problem.  If you have evidence to the
contrary, please submit it in a bug report to [email-masked].

>    concept of a single DNS configuration file?

Of course not - that's why it says "or by some other, equivalent
method for configuring zone data".  Any configuration method that
unambiguously maps a zone name into a collection of RRs is acceptable.
All that section is saying is that once this collection of RRs has
been defined, transporting it by means of zone transfers must not
cause it to be altered.

>    I object to the use of

The use of master files to define zone data is not a BIND-specific
notion, it is an RFC1035 notion, and as I said, the draft specifically
allows alternative configuration mechanisms.

>    which takes records from all sections. This requirement violates RFC

Alan Barrett already responded to this, and I concur with his response.

>    which simply closes the connection. This requirement violates RFC

The requirement to send a response is already implicit in the nature
of the DNS protocol as a query-response protocol.  The fact that the
quoted paragraph reiterates this requirement is incidental; its main
point is to specify the format of the response, which is not clear in
RFC1034.

In my opinion, a server which closes the connection is not violating
the AXFR protocol, it is refusing to speak it and therefore outside
the scope of the draft.

>    violates RFC 2119, section 6.

IDs and RCODEs are checked in all other contexts of the DNS protocol,
and I don't think it was the intent of RFC1034/1035 to make AXFR an
exception.  The draft is attempting to capture this presumed intent to
the extent possible, making specific exceptions only where required
for interoperability with existing implementations.

>    behavior of my AXFR client.

I agree that the issues of spoofing and multiplexing are irrelevant.
They were not the reasons for the current wording of the draft.

>    recommendation that does not take full account of existing practice.

Responses to other forms of DNS queries contain a copy of the
question, and again I don't see any indication in RFC1034/1035 that
AXFR was intended to be an exception.

>    sense for AXFR and is not used by existing AXFR clients. This proposal

I have no problem with adding such a requirement, but wouldn't that
violate RFC 2119, section 6?

>    however, completely out of whack with how most versions of BIND work.

I have already agreed to change this into a SHOULD.

>   labelled and reviewed as a revision of the protocol.

The draft *is* a revision of the protocol as it replaces "The first
and last messages must contain the data for the top authoritative node
of the zone" with "The first and last RR transmitted must be the SOA
record of the zone".  Whether any other aspects of the draft should
also be characterized as changes to the protocol will depend on your
particular interpretation of RFC103[45].  In any case, I fully expect
the draft to be reviewed as a revision of the protocol.

As for using the word "clarifications" in the title, that follows the
example of RFC2181, which also updated RFC1034.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 05 Jul 2001 21:11:01 -0700

Kevin Darcy writes:
> Section-based extensibility *is* part of the protocol

Section-based extensibility is _not_ part of the existing AXFR protocol.
In particular, the requirement that clients ignore AU records and AR
records is _not_ part of the existing AXFR protocol. It is new in the
axfr-clarify document. It is not compatible with the installed base.

> If your client croaks on unexpected RR's in Authority or Additional of
> an AXFR response, it's broken.

My AXFR client doesn't look for sections. It treats all records as part
of the zone. It works just fine. It is in full compliance with the
required DNS standards.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Fri, 06 Jul 2001 04:00:58 -0700

Andreas Gustafsson writes:
> exception.

I think it would help if you read the DNS specifications. ID checking
and RCODE checking are explicitly given as part of the recommended
resolution algorithm in RFC 1034 section 5.3.3. They are not part of the
zone-transfer protocol in section 4.3.5.

Zone-transfer clients are not resolvers. The principle that they should
follow resolver rules is a figment of your imagination.

> exactly the same as those in the child.

RFC 1034 also says that a node with a CNAME record ``should'' have no
other data, and that in the last step of delegation one ``should'' add
NS records to the parent zone, and that lame delegations ``should'' be
ignored, and that it is essential that temporary errors ``should not''
be signalled as permanent errors.

> I have no idea what you are talking about here.

I've been told, by a source I believe, that some recent versions of BIND
reject zones of the type I described as containing ``non-glue records.''
Please investigate, and then explain the facts to us.

> of the DNS protocol as a query-response protocol.

Nonsense. Unauthorized clients do not have any right to a response.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Fri, 06 Jul 2001 04:00:39 -0700

> dns-01.ns.aol.com glue as part of referrals out of any zone other 

No, that's not enough. It would help if you read the examples of poison
in http://cr.yp.to/djbdns/notes.html.

Let's say I'm a .com server, and I receive the records

   money.microsoft.com NS dns-01.ns.aol.com
   money.microsoft.com NS dns-02.ns.aol.com
   dns-01.ns.aol.com A 207.46.230.218
   dns-02.ns.aol.com A 207.46.230.218

from a microsoft.com AXFR server. Suppose I follow your bogus model and
keep these records in the microsoft.com zone for referrals out of the
microsoft.com zone. A cache asks me about www.aol.com, and I provide the
records

   aol.com NS dns-01.ns.aol.com
   aol.com NS dns-02.ns.aol.com
   dns-01.ns.aol.com A 152.163.159.232
   dns-02.ns.aol.com A 205.188.157.232

from the .com zone. The cache saves these records, because it trusts
.com servers to provide *.com information. The cache then asks the AOL
servers about www.aol.com, but those servers happen to be down. Later
the cache asks me about foobar.money.microsoft.com, and I provide the
records

   money.microsoft.com NS dns-01.ns.aol.com
   money.microsoft.com NS dns-02.ns.aol.com
   dns-01.ns.aol.com A 207.46.230.218
   dns-02.ns.aol.com A 207.46.230.218

following your bogus model. The cache saves these records, overwriting
the previous dns-01.ns.aol.com and dns-02.ns.aol.com information. Later
the cache asks 207.46.230.218 for information about www.aol.com.

It is, as I said, essential for the .com server to discard the aol.com
information from the microsoft.com AXFR servers.

---Dan

P.S. Is BIND 9 vulnerable to this attack? Or does it discard the aol.com
information, destroying the ``identity'' of the zone?

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Jul 2001 04:55:13 -0700

Date:        Thu, 05 Jul 2001 20:48:55 -0700
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | RFC1034 says the records in the parent "should" (not "must") be
  | exactly the same as those in the child.

First - be very careful in interpreting the wording of any RFC more than
a few years old (say anything much older than 2119).   1034 even predates
1122/1123 which were where the MUST/SHOULD stuff was introduced - though it
was being developed at the same approximate time as host requirements was.
But back then, the MUST stuff in docs was quite new, and was being kept
for the docs that really need it (which is, ones that actually set out
to specify protocol conformance, rather than just specify protocols).

That an old doc doesn't use the word "must" doesn't necessarily mean
anything at all about what is actually required.  You have to actually
read what is saying, and understand why to be able to deduce that in most
cases.

  | This is an operational recommendation, not a protocol requirement,

It is actually a DNS database requirement - there is supposed to be
a single set of data, and clients should always get the same answers,
no matter who they ask.

Because of the lack of protocol support (probably for good reason)
enforcing this turns into an operational matter - but it isn't just
for operational convenience that the data is supposed to be the same.

  | and in practice, discrepancies are extremely common and must be dealt
  | with by the protocol.

Yes, the DNS does plan for outdated data, and this one in particular
is one of the worst examples of that, as it generally requires some form
of human intervention to cause the servers to become reconciled (someone
has to ask the parent to update its delegation).

The protocol does need to deal with that, and generally it does.

I certainly agree that when a zone transfer is attempted, it should not
matter what other zones the server of the AXFR happens to be authoritative
for (much less what other RRs it might happen to have in its cache).
That BIND managed to ignore this requirement for almost ever (until BIND9)
has been a long standing acknowledged bug in BIND.   But if it hadn't been
for that bug, I doubt that anyone would seriously be suggesting otherwise.

This is just another example of returning the same answers, any two servers
for the same zone, holding the same copy of the that zone (equal serial
numbers) should return the same answers when data is extracted from that
zone to be used in a reply - whether that's a reply to a query for an A,
or a reply to an AXFR request.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 06 Jul 2001 15:23:45 -0700

> Section-based extensibility is _not_ part of the existing AXFR protocol.

Why are you referring to AXFR as a separate protocol? By your own logic, if
it were a separate protocol, it would run on a separate port number. It
doesn't, ergo it's not a separate protocol. It's *part* of the overall
DNS protocol, and thus inherits the rules and the assumptions of
DNS generally, except where explicitly overridden.

> axfr-clarify document. It is not compatible with the installed base.

RFC 1034 just said that the messages of a zone transfer "carry all of the
[...] RRs from the zone". Now, where does a DNS client (let's not split
hairs again over whether an AXFR client is a DNS client or not) normally
look for answers to its question, assuming that the question *was* in fact
answered, as opposed to referred, refused or whatever? In the Answer
Section of course! So it's a perfectly reasonable assumption -- and a
perfectly reasonable interpretation of the original, unclear specification
of AXFR -- that the RR's of the zone will be in the Answer Section, and as
far as I know all implementations except yours are based on this
assumption. This clarify draft simply does what it is supposed to in this
instance -- it _clarifies_ the original specification/interpretation. Now,
logically, if all of the RR's of the zone being transferred belong in the
Answer Section, then it makes no sense for them to appear in other
sections, since the other sections serve purposes besides simply answering
a client's question. Assuming that all RR's in an AXFR response are data
for the zone, regardless of section, would be like assuming that
*everything* you get from a grocery store is edible or drinkable (including
the glass and/or plastic packaging and/or containers)or that every part on
a DaimlerChrysler automobile had been safety-tested and was designed to
last more than a few months (just kidding about that second simile :-).
Function often depends on context, and DNS section distinctions are
contextual. An RR in the Answer Section answers the question asked. A RR in
some other section serves some other purpose, so in an AXFR transaction,
where the question was, basically,"what are the contents of the zone?" it
shouldn't be considered part of the zone data.

So any RR's appearing in other sections should be ignored by an
AXFR client, unless that client happens to know about specific extensions
which use those particular RR's in Authority or Additional, e.g. TSIG or
EDNS0. The language "ignore any unexpected RR's" captures this concept
quite succinctly I think. This facilitates the development of future
extensions, which a given client may "expect" or not, depending on its age
and/or level of standards-conformance, and shouldn't be inhibited by your
wish/desire to be completely "section-agnostic" in your AXFR client.

To take another tack: Dan, how do you propose that extensions to AXFR --
including generic extensions to DNS that might coincidentally be applied to
AXFR responses -- be reliably implemented *without* making AXFR into a
totally separate protocol, running on a different port and *without* a
guarantee that clients will ignore unexpected RR's in sections other than
the Answer Section? If I propose a FOOBAR extension tomorrow, which puts a
new type of RR in the Additional Sections of, among other responses,
AXFR responses, is your client going to foolishly think that new record is
part of the zone? For that matter, does your client today think that
TSIG or OPT records are part of the zone being transferred? If you treat
all of the sections of an AXFR response, collectively, as a data container,
you leave almost *no* room for incremental extensibility of the
DNS protocol as it may apply to AXFR responses (do you perchance think all
of those potential extensions can fit in the unused bits of the header?).
Given your overall views on the usefulness of AXFR (or perceived lack of
it), I'm not surprised that you would try to stifle its (co-)evolution, but
surely you can't expect the rest of the DNS community to acquiesce to such
Luddism.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: Fri, 06 Jul 2001 22:25:11 -0700

Kevin Darcy writes:
> it's a perfectly reasonable assumption -- and a perfectly reasonable
> interpretation of the original, unclear specification of AXFR -- that
> the RR's of the zone will be in the Answer Section

I agree. There's no dispute about this. AXFR _servers_ have to put all
the records into the answer section. Any server that violates this rule
will have interoperability problems with some AXFR clients.

Now, given a stream of DNS messages, with empty authority and additional
sections, how does the AXFR _client_ extract all the records?

There are several methods that work. I'm using one. BIND uses another.
The choice of method has no effect on interoperability. axfr-clarify is
violating RFC 2119 section 6 by requiring a particular parsing method.

> If I propose a FOOBAR extension tomorrow, which puts a new type of RR
> in the Additional Sections of, among other responses, AXFR responses,

Then you are an idiot. You are pointlessly breaking compatibility with
working AXFR clients deployed at thousands of sites. Put your protocol
on a new port, and stop demanding that I pay attention to it.

> (let's not split hairs again over
> whether an AXFR client is a DNS client or not)

Zone transfers are requested by name servers. The zone-transfer protocol
is described in RFC 1034 section 4: ``NAME SERVERS.''

Resolution is requested by caches (``resolvers''). The resolution
protocol is described in RFC 1034 section 5: ``RESOLVERS.''

See RFC 1035, page 6, for a data-flow diagram showing the different
roles of caches and name servers.

---Dan

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 10 Jul 2001 06:37:14 -0700

Look, Dan, if AXFR clients are going to be a special case to the general
rule that DNS clients only look for direct answers to their question, when
definitively answered, in the Answer Section, then surely it makes more
sense to declare AXFR a separate protocol, with a separate port assignment,
than to declare every incremental extension to DNS, present and future,
which might happen to put RR's in the non-Answer sections of AXFR
responses, a separate protocol requiring a separate port assignment. Why
should the many suffer for the sake of the one? Yet I don't see you pushing
for AXFR to use a different port number. TSIG and EDNS0 are already with
us, and as far as I know it is legal for either or both to be transmitted
in an AXFR response; are you seriously suggesting that we already need 2
new port assignments, with more to be obtained as new extensions are
adopted? That's madness. It's obviously not scalable for all nameservers to
have to listen on a new port every time another protocol extension comes
down the pike. And do you really want to make a living hell for firewall
administrators who have to change the rulesets on all of their boxes every
time a new port is defined for general use?

The "ignore unexpected RR's" language of the clarify draft allows these
incremental extensions to reliably co-exist with AXFR without drastic
measures like forking off new port assignments. The only thing that is lost
is the opportunity for an AXFR client to be "section-agnostic", but you
have IMO fallen far short of demonstrating that "section-agnosticism" has
any practical value, let alone that its preservation is worth stunting the
evolution of extensions to the DNS protocol if and whereever those
extensions may coincidentally apply to AXFR responses. Between the two
types of interoperability under inspection here -- interoperability between
AXFR and protocol extensions, on the one hand, and interoperability between
non-standards-conforming servers and "section-agnostic"-wannabe clients, on
the other -- the type of interoperability which facilitates long-term
growth and evolution should be preferred.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: Tue, 10 Jul 2001 18:13:07 -0700

Kevin Darcy writes:
> TSIG and EDNS0 are already with us, and as far as I know it is legal
> for either or both to be transmitted in an AXFR response

Only by bilateral agreement.

> are you seriously suggesting that we already need 2 new port
> assignments, with more to be obtained as new extensions are adopted?

Of course not. You could easily squeeze the entire OSI protocol suite
into a protocol running on a single TCP port.

You have to be careful, however, if you want to use port 25, or port 80,
or port 53. You have to maintain compatibility with the installed base.
That's why protocol designers often use new ports.

Terrified of new ports? Fine. Use a new EXFR query type. This is not
rocket science.

> you have IMO fallen far short of demonstrating that
> "section-agnosticism" has any practical value

I have thousands of sites whose adminitsrators don't want to be forced
to upgrade their working DNS software. If you don't think compatibility
has ``practical value,'' you're an idiot.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 11 Jul 2001 00:20:06 -0700

Date:        Tue, 10 Jul 2001 18:13:07 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I have thousands of sites whose adminitsrators don't want to be forced
  | to upgrade their working DNS software.

This is a nonsense argument - before anyone would possibly be required
to upgrade their working software because of changes to AXFR that put
something different in the auth/additional sections than what is in
the answer section, all those administrators are going to have upgraded
their software for other reasons anyway (and not necessarily all for the
same one).   What's more, even if a few haven't, it would only matter if
their peer axfr servers actually use whatever new might eventually get
defined.

All that is needed now, or anytime in the forseeable future, is that you
add the one line of code it takes to stop processing at the end of the
answer section, instead of at the end of the packet, and include that in
the distribution.  You don't have to suggest to anyone that they upgrade,
just make a version that works this way available.

Then, long before it is ever going to matter, the thousands of sites
are going to be 10's of sites, at most.   And most of then may never
notice.  And this is all *if* anything is ever defined to use the
other sections.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Jul 2001 00:21:00 -0700

> Only by bilateral agreement.

We've already stipulated that AXFR servers shouldn't be sending zone data
outside of the Answer Section, so this whole issue is moot if every server
could be trusted to do The Right Thing all of the time. But if we want AXFR
clients to be robust and deal reasonably with a server that does The Wrong
Thing, however, then we have to deal with unagreed-upon OPT or TSIG records
as well as non-Answer-Section zone data. The clarify draft says "ignore the
RRs". You seem to be challenging that and saying instead "no, treat them as
zone data". Which means if you get a wayward OPT or TSIG record, your
client presumably will mistake that for zone data, whereas most other
clients will just ignore them if they don't recognize them or there is no
bilateral agreement to use them. This is an interoperability problem. The
same records are being treated differently depending on the idiosyncrasy of
the implementor. This is _exactly_ the kind of thing that a clarify draft
is meant to clear up. And when a protocol is clarified, it's certainly not
unusual for software which made the "wrong" assumption (even if it didn't
seem "wrong" at the time, because the specification was unclear) to have to
change to conform to the clarified standard.

> That's why protocol designers often use new ports.

Or they use otherwise-unused sections of a response...

> Terrified of new ports? Fine. Use a new EXFR query type. This is not

Oh, great. So now we're defining new query types for every extension,
whether it functionally needs it or not. Or, should I say, every
*combination* of extensions (one for TSIG only, one for EDNS0 only, one for
EDNS0+TSIG, etc.)? We'll chew up the QTYPE range pretty quickly that way...

> has ``practical value,'' you're an idiot.

And if you think protocol-implementing software can be immutable, even in
the face of protocol clarifications and extensions, then you're... well...
I've sworn off name-calling so I'll abstain. Suffice it to say, speaking as
an administrator, I view claims about "software that will never need to be
upgraded" with about as much skepticism as claims about perpetual-motion
machines.

- Kevin

---

From: Brian Wellington <[email-masked]>
Date: Wed, 11 Jul 2001 00:22:06 -0700

> Only by bilateral agreement.

A TKEY can spontaneously be added to a response.  See RFC 2930, section 5.
I don't think this is a good idea, but it is a spec.  It says

	This SHOULD only be done if the server
	knows the querier understands TKEY and has this option implemented

but that doesn't prevent a server from doing it in other cases.  It would
be completely legal for a server to implement this, and it would cause
your AXFR client to import a TKEY record into the zone.

> Terrified of new ports? Fine. Use a new EXFR query type. This is not

Which, for every DNS implementation except yours, would be identical to
AXFR.

> has ``practical value,'' you're an idiot.

No one's forcing users to do anything.  This is a fairly minor point, and
even if your client is non-compliant, it has virtually no interoperability
issues.  I wouldn't go out of my way to update sites that I administered
just because of this.

Brian

---

From: Andreas Borchert <[email-masked]>
Date: Wed, 11 Jul 2001 08:22:20 -0700

On Wed, Jul 11, 2001 at 12:20:06AM -0700, Robert Elz wrote:
> same one).

This argument is not nonsense for administrators using djbdns and
other software packages from the same author. Dan designes his software
packages to be minimal, fast, and secure which allows him to keep them
stable for a long time. Qmail, for example, did not change for multiple
years. For this reason, many users of Dan's packages prefer them because
they remain secure and stable for a long time. Running Qmail and djbdns
means that you do not have to look for new security holes and you can
keep them running unchanged for many years.

This advantage is destroyed once protocols are changed in an incompatible
way.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Jul 2001 21:26:13 -0700

Andreas Borchert wrote:

> stable for a long time.

What's "minimal" about looking for zone data in sections where it doesn't
belong? Section-agnosticism is not necessary for minimalism, security or
performance, it's just a "feature" Dan made up to justify a fairly mundane
design decision he made in his AXFR client which in hindsight probably should
have been done a different way.

- Kevin

P.S. ($500 to the first person who proves that the following compromises
security or substantially impacts performance. As is usual with such
guarantees, my judgment is final as to whether a security-compromise or
substantial-performance-impact in fact exists.)

*** axfr-get.c.old      Sun Jan 21 21:51:44 2001
--- axfr-get.c  Wed Jul 11 21:03:38 2001
***************
*** 352,357 ****
--- 352,358 ----

      pos = x_copy(packet.s,packet.len,0,out,12);
      uint16_unpack_big(out + 4,&numqueries);
+     uint16_unpack_big(out + 6,&numanswers);

      while (numqueries) {
        --numqueries;
***************
*** 358,366 ****
        pos = x_skipname(packet.s,packet.len,pos);
        pos += 4;
      }
!     while (pos < packet.len) {
        pos = doit(packet.s,packet.len,pos);
!       if (!pos) die_parse();
      }
    }

--- 359,368 ----
        pos = x_skipname(packet.s,packet.len,pos);
        pos += 4;
      }
!     while (numanswers) {
!       --numanswers;
        pos = doit(packet.s,packet.len,pos);
!       if (!pos || (pos > packet.len)) die_parse();
      }
    }

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 12 Jul 2001 11:36:50 -0700

The problem is not the amount of code. The problem is the time and
effort required to deploy that code at thousands of sites.

If you extend a protocol without maintaining compatibility, you are
inflicting completely unnecessary costs on people who don't want to use
your extension.

Suppose, for example, that you start randomly sending TKEY records to
caches that haven't asked for them. My cache has no special knowledge of
TKEY, but it follows the letter and spirit of the RFC 1123 rules on new
record types, as explained in http://cr.yp.to/djbdns/newtypes.html; so
it will save those records if they're within your bailiwick, and return
them in response to appropriate queries.

Suppose that---as Brian Wellington seems to suggest---these cached TKEY
records will cause your own TKEY-aware clients to fail. (I don't know if
this is actually the case. I haven't read the TKEY specification, nor do
I see any reason that I should. IPSEC works.)

Your extension is then incompatible with the installed base. If you
insist on using it, you are creating failures. If you insist that I
change my code to work around these failures, you are imposing costs on
people---my users---who don't want to use your extension, and you will
still have to wait many years before your extension is safe to use.

That is not sensible engineering. You should have designed a compatible
extension, an extension that would be safe to use immediately. 

I cannot imagine why anyone would argue in favor of an incompatible
extension, except as a deliberate attempt to impose costs on other
people. I accuse the BIND company of doing precisely that.

Kevin Darcy writes:
> Section-agnosticism is not necessary for minimalism, security or
> performance, it's just a "feature" Dan made up to justify a fairly
> mundane design decision

What are you talking about? I've said nothing of the sort. This was a
trivial implementation decision: out of the many possible ways to
correctly parse an AXFR response message, I chose the one that I found
easiest to write.

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Thu, 12 Jul 2001 13:55:09 -0700

> effort required to deploy that code at thousands of sites.

No one but you thinks it's necassary that all of these sites deploy the
new code.

> inflicting completely unnecessary costs on people who don't want to use

True.  I don't think anyone disagrees with this.

> I see any reason that I should. IPSEC works.)

I'm suggesting no such thing.  I'm saying that your server will cache the
records, which could lead to strange results in the future.  For example,
the cache TKEY records would be included in the response to an ANY query.

For the record, your comments about BIND 9's handling of unknown types
in http://cr.yp.to/djbdns/newtypes.html are wrong.

> extension, an extension that would be safe to use immediately.

Exactly which extension are you complaining about?  No other
implementations have these problems.

> people. I accuse the BIND company of doing precisely that.

No one's arguing for an incompatible extension.  The point is that there
are extensions already that are reasonable given the spirit of the
original AXFR specification.  The axfr-clarify draft clarifies the AXFR
specification, which makes these extensions fully legitimate.

I'm fairly sure no decisions have ever been made purely to make your life
more difficult.

Brian

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 12 Jul 2001 14:41:53 -0700

> extension, an extension that would be safe to use immediately.

Dan, you really *shouldn't* be treating all RR's in an AXFR response as
zone data. Whether or not TKEY was implemented shortsightedly is rather a
moot point, since implementations are already starting to use it as it is
currently specified. And I'm sure other extensions will probably want to
use Authority and/or Additional, and won't necessarily think to treat AXFR
responses as a special case. You can't expect the rest of the protocol to
evolve around AXFR while it stays static. If you want your software to be
robust, I don't think you have any other choice but to ignore unexpected
RRs in Authority or Additional, regardless of what the clarify draft says,
because, bilateral agreement or not, you're going to be *seeing* those RRs,
and treating them as zone data is bound to cause problems.

> What are you talking about? I've said nothing of the sort.

Perhaps I misinterpreted the following statement then:

>   of the zone. It works just fine.
>
I read this as praise of section-agnoticism.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 12 Jul 2001 16:14:28 -0700

Brian Wellington writes:
> I'm saying that your server will cache the
> records, which could lead to strange results in the future.

I don't know what you mean by ``strange.'' Is there a problem, or not?
Will a TKEY-aware client have trouble if I forward it a copy of a TKEY
record that someone else spontaneously sent me?

If so, the TKEY extension is broken. You said that TKEY servers could
spontaneously send TKEY records. Forwarding the records---treating them
as zone data---is indisputably correct behavior for my cache. See RFC
1123 section 6.1.3.5. See also http://cr.yp.to/djbdns/newtypes.html.

If, on the other hand, there is no problem, then why did you claim that
my AXFR client shouldn't forward the records?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 12 Jul 2001 16:15:01 -0700

Brian Wellington writes:
> The point is that there are extensions already that are reasonable
> given the spirit of the original AXFR specification.

Nothing in the original specification requires that AXFR clients stop
reading packets at the end of the answer section. If you dispute this,
please quote the text that you believe imposes such a requirement.

> No one but you thinks it's necassary that all of these sites deploy the

I have repeatedly asked why I should make this change to the code. What
exactly is the benefit?

The answer from your coworker Mark Andrews is that he might someday do
something that _fails_---causes ``damage,'' he says---if it encounters
the unchanged code. He says he wants to avoid ``breaking things.''

But changing the code isn't enough to prevent these failures. The
changed code would have to be _deployed_. That's the cost I'm talking
about. Deployment takes time and effort.

Is the BIND company backing away from demanding that my users suffer
this cost? If so, I ask again: What exactly is the benefit of my making
this change to the code?

> in http://cr.yp.to/djbdns/newtypes.html are wrong.

The page was accurate when I wrote it. Are you saying that BIND was
subsequently fixed? Which versions?

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Fri, 13 Jul 2001 17:50:42 -0700

> please quote the text that you believe imposes such a requirement.

Dan, you're missing the point.  The whole point of the axfr-clarify draft
is that the original specification is unclear.  Obviously there is no such
stated requirement, or we wouldn't be having this painfully long argument.

> the unchanged code. He says he wants to avoid ``breaking things.''

That seems like a perfectly reasonable point.

> about. Deployment takes time and effort.

Not true.  If you changed the code now, deployment would naturally occur
by the time incompatible features were used.

> this cost? If so, I ask again: What exactly is the benefit of my making

Compatibility with future extensions and the future standard.  And the
fact that it would take less time than continuing to argue.  And it
doesn't hurt anything.

> subsequently fixed? Which versions?

9.1.0.

Brian

---

From: Brian Wellington <[email-masked]>
Date: Fri, 13 Jul 2001 17:50:51 -0700

> record that someone else spontaneously sent me?

There would be a problem if a client was sanity checking the response of
an ANY query, and saw a TKEY record in the answer section.  Seeing a
meta-type where it's not expected is bad.

> 1123 section 6.1.3.5. See also http://cr.yp.to/djbdns/newtypes.html.

A spontaneous TKEY will only be in the additional section, which means
that it shouldn't be treated as zone data.  If it was in the answer
section, I'd agree that it would be zone data, and that it is a broken
extension.

> my AXFR client shouldn't forward the records?

Because they're not part of the zone, as indicated by the fact that
they're in the additional section.

Brian

---

From: "D. J. Bernstein" <[email-masked]>
Date: Fri, 13 Jul 2001 21:37:06 -0700

Suppose I'm a DNS cache with no special knowledge of type TKEY or type
XYZZY. Someone asks me for all nominum.com records of type XYZZY.

One of the nominum.com servers gives me the following response,
including a spontaneously generated TKEY record, which Wellington says
is not prohibited by the TKEY specification:

   query: XYZZY nominum.com
   answer: nominum.com 3600 XYZZY ...
   authority: nominum.com 3600 NS ...
   authority: nominum.com 3600 NS ...
   authority: nominum.com 3600 NS ...
   additional: gns1.nominum.com 3600 A ...
   additional: gns2.nominum.com 3600 A ...
   additional: nominum.com 3600 TKEY ...

All those records are within nominum.com, so I cache all of them.

I do _not_ ignore the two records of unrecognized types. As stated in
RFC 1123, section 6.1.3.5: ``A name server may acquire, via zone
transfer, RRs that the server doesn't know how to convert to printable
format. A resolver can receive similar information as the result of
queries. For proper operation, this data must be preserved.''

I do _not_ ignore the three authority records, and I do _not_ ignore the
three additional records. Wellington's comment ``they're not part of the
zone, as indicated by the fact that they're in the additional section''
is completely out of touch with the existing DNS protocol.

Someone now asks me for all nominum.com records of type *. I am entirely
within my rights to respond with all the cached nominum.com records,
including the TKEY record:

   query: * nominum.com
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 TKEY ...
   answer: nominum.com 3597 XYZZY ...

Wellington claims that TKEY-aware clients may barf on this response.

The inescapable conclusion is that the TKEY protocol is broken. It is
incompatible with the existing protocol. It has to be fixed.

How can a broken protocol be used as an argument against the behavior of
my AXFR implementation? I'm indisputably allowed to save records from
the authority section and the additional section when I'm a cache, so
why can't I do the same when I'm an AXFR client?

---Dan

P.S. This particular failure won't actually happen with our current
implementations: my cache will stop its * response after the NS records,
and the nominum.com servers won't spontaneously generate TKEY records in
the first place. But the specifications don't require these protections.

P.P.S. Each of my messages, as sent, contains the following statement in
the header: ``Copyright 2001, D. J. Bernstein. My transmission of this
message to you does not constitute a copyright waiver or any other
limitation of my rights, even if you have told me otherwise.'' This
statement is being discarded somewhere in Randy Bush's mail system.

---

From: Robert Elz <[email-masked]>
Date: Sun, 15 Jul 2001 09:54:59 -0700

Date:        Fri, 13 Jul 2001 21:37:06 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I do _not_ ignore the three authority records, and I do _not_ ignore the
  | three additional records. Wellington's comment ``they're not part of the
  | zone, as indicated by the fact that they're in the additional section''
  | is completely out of touch with the existing DNS protocol.

Could you possibly explain, in very plain words, just what it would
hurt for you to alter your implementation to make it that only the answer
section in an AXFR was used as zone data?

Forget the "upgrade costs" argument - no-one is going to be asked to
actually install the changed version any time soon.   Is there any other
reason that this change would do harm?

There's no dispute that the zone must all be placed in the answer
section by the AXFR server, what real harm can there be in expecting
the AXFR client to only look there?

This isn't completely out of touch with anything - it was the way that
AXFR was always intended to be, but, like a lot of old internet specs,
stuff that was obvious to everyone was sometimes omitted (no-one saw the
need to actually write it down).   That's what is attempting to be fixed
now.   This is even one where (until recently it seems) no-one had ever
even managed to not implement correctly, and in the DNS world, that's
near remarkable - even the very clearest parts of the spec have managed
to get broken implementations...

  | P.P.S. Each of my messages, as sent, contains the following statement in
  | the header: ``Copyright 2001, D. J. Bernstein. My transmission of this
  | message to you does not constitute a copyright waiver or any other
  | limitation of my rights, even if you have told me otherwise.'' This
  | statement is being discarded somewhere in Randy Bush's mail system.

Yes, the moderation seems to drop all but a few headers, and re-send as
a new message (I have seen other lists do the same, even without any
human involvement).   Not that it should matter to your missing header,
as (notwithstanding the noise going on in poisson at the minute) copyright
is implied without a notice (even in the US these days I gather...)

kre

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 16 Jul 2001 16:44:36 -0700

The key word in the RFC 1123 verbiage is "acquire". The only data that you
"acquire" in an AXFR transaction are Answer-section RRs. Anything else in
the response is to be considered "meta-data", and if you don't understand
it and/or didn't ask for it, you should ignore it.

Similarly, for ordinary queries, I don't know that "result", as used in the
RFC 1123 verbiage you quoted, extends beyond the direct answer to the
query, i.e. the Answer Section. Maybe it also encompasses the contents of
the Authority Section in the case of a referral...

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: Tue, 17 Jul 2001 13:19:34 -0700

Andrew Brown asks why my cache ``promotes'' additional records to answer
records. (Apparently his message was discarded by Randy Bush.)

Answer: This is how caches have always worked. The additional A record
that comes with an MX record, for example, is returned as an answer in
response to subsequent A queries. RFC 2181 is simply wrong.

Are there any further questions about my TKEY example? The failure of
TKEY to work with AXFR clients is just like the failure of TKEY to work
with caches. Does everyone agree that the cache is behaving properly?
Obviously the TKEY specification needs to be corrected.

> section in an AXFR was used as zone data?

Could you possibly explain just what it would hurt for the BIND company
to alter _their_ implementation to handle data in other sections?

After all, I might want to deploy an optional AXFR extension that---
without wasting space---communicates a few extra bits of information by
putting records into AU or AR instead of AN. This extension would be
incompatible with current versions of BIND, so BIND has to be fixed!

Now, I realize that there are a million BIND hosts out there, including
tens of thousands running ancient versions of BIND, but, gee, surely
they'll all upgrade before I deploy my incompatible extension. If they
don't, we'll use BIND's ``remote root upgrade'' feature!

Whaddya mean, optional extensions have no right to break compatibility?
We're talking about the _future_, damn it! Bold new paths! OSI! I know
the BIND company doesn't care about these things, but they can't expect
the rest of us to acquiesce to their Luddism.

Maybe you're not swayed by practical compatibility concerns. Well, how
about the spirit of RFC 1034? The RFC says that zone transfer messages
carry all the zone records. It _doesn't_ say that the records are in the
answer section. Obviously clients are meant to read all the sections!

---Dan

---

From: Andrew Brown <[email-masked]>
Date: Tue, 17 Jul 2001 14:24:36 -0700

>records. (Apparently his message was discarded by Randy Bush.)

randy didn't.  his list server did.  but no matter.

>response to subsequent A queries. RFC 2181 is simply wrong.

additional records are glue data.  they are there to assist the
recursing name server in looking up the answer.  they are *not* an
answer.  i would perhaps argue that an application using a resolver
should be able to use additional records as answers, but not a name
server.

>Obviously the TKEY specification needs to be corrected.

if you receive a tkey record in response to a simple query, there's no
conceivable reason you should be able to answer an axfr query that
might contain the tkey.  if a server returns a tkey to your axfr
query, it should not be appended to the zone since it's not in the
answer section.  they question (axfr) asks for all records in the
zone.  the zone itself is the answer, the tkey is additional and not
an answer per se.

my understanding was that additional (or glue) records are supposed to
be helpful hints, not answers for servers.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 17 Jul 2001 16:58:55 -0700

> Obviously the TKEY specification needs to be corrected.

The problem of servers caching meta-RRs is real, but it is not
specific to TKEY, and it has nothing to do with AXFR.  I think the
best way to solve it is to only allocate meta-RR types from the range
reserved exclusively for that purpose (128-255, see RFC2929), and to
make caching servers ignore rather than cache unknown records whose
types fall within that range.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 17 Jul 2001 17:00:56 -0700

> incompatible with current versions of BIND, so BIND has to be fixed!

And someone else might want to deploy an optional extension that
communicates more bits than can be represented using the section
distinction, by encoding it in RRs that are not part of the zone data.
This extension would be incompatible with current versions of TinyDNS.

In other words, neither method of extension is currently safe - both
will cause interoperability problems with at least one deployed
implementation.  We can make one or the other (but not both) become
safe at some point in the future by unambiguously specifying that
non-answer-section records are treated as zone data or are ignored,
respectively.

The draft as currently written reflects the choice to ignore the
records, because I believe it this choice is more consistent with the
spirit of RFC103[45], is implemented by a larger proportion of
deployed servers, allows more useful forms of extension, and enjoys
greater support in the working group.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: Tue, 17 Jul 2001 16:59:04 -0700

The BIND 9 cache saves records from the additional section and provides
those records as answers to subsequent queries. Same for the BIND 4
cache, the BIND 8 cache, and my cache. Does anyone seriously believe
that this is incorrect behavior?

We've also been told that the BIND 9.1.0-and-newer cache, just like my
cache, handles unrecognized record types as per RFC 1123. Does anyone
seriously believe that this is incorrect behavior?

Imagine a TKEY2 extension that's similar to the current TKEY but uses a
new record type, unrecognized by BIND 9.1.0. Then

   spontaneous TKEY2 server  -->  BIND 9.1.0 cache  -->  TKEY2 client

will produce exactly the failures I've described, except with TKEY2 in
place of TKEY. Does anyone dispute this?

Similarly, if you rip the TKEY support out of BIND 9.1.0, and you put
that cache between a spontaneous TKEY server and a TKEY client, you get
failures. Does anyone dispute this?

The inescapable conclusion is that the TKEY extension is broken. It is
incompatible with the unextended protocol. It has to be fixed. How can
anyone use a broken extension as an argument against my AXFR client?

These are fundamental interoperability issues. They have to be settled.

Andrew Brown writes:
> recursing name server in looking up the answer.

Sorry, but that simply isn't how DNS works.

RFC 1034 defines the additional section as carrying ``RRs which may be
helpful in using the RRs in the other sections.''

I already gave the obvious example: A records associated to MX records.
The A record is helpful---it saves time. You claim that the A is glue;
that's rarely true. You claim that it's ``to assist the recursing name
server in looking up the answer''; that's false. 

There's no support in RFC 1034, RFC 1035, or RFC 1123 for the notion
that additional records are second-class citizens. That notion was
invented by Paul Vixie as a failed attempt to stop cache poisoning. See
http://cr.yp.to/djbdns/notes.html.

I would have objected to RFC 2181's credibility rules if I had been
involved in DNS programming back then. I object to them now as being
useless, harmful, and out of line with existing practice.

---Dan

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 17 Jul 2001 17:01:04 -0700

D. J. Bernstein wrote:

> response to subsequent A queries.

So what's your point? A totally *different* server may answer the A query.
Additional Section records are viewed as inherently less "credible" because
the client can't easily tell where they come from vis-a-vis authoritative data
or cache. If you really need credible data, you ignore what's in the
Additional Section and query the names independently. Or use DNSSEC.

> Obviously the TKEY specification needs to be corrected.

No, TKEY is just fine. A "section-agnostic" cache is just as broken as a
"section-agnostic" AXFR client. Where would we be if caches started treating
referrals or NCACHE SOA records as regular answers? The DNS packet format was
sectioned for a *reason*. Different sections provide different contexts, and
an RR in one section may have a different meaning than an identical RR in some
other section. That's the way it's always been, and the way it was *meant* to
be. Whence comes this strange notion that one can take *all* RRs in a
response, regardless of section, and treat them on an equivalent basis? That's
never been the case. Why even _have_ sections in that case?

> incompatible with current versions of BIND, so BIND has to be fixed!

But what is the inherent *value* of putting zone data into Authority or
Additional, Dan? The value of putting metadata into Authority or Additional of
an AXFR response is specifically to segregate it from the zone data so the
client doesn't get confused. A TKEY, for example, shouldn't be considered part
of the zone data, so by segregating it into Additional, we help avoid
misinterpretation. Section-agnosticism ruins this mechanism, and means that
clients now have to sift through all the records and make decisions about
whether or not an RR is part of the zone data, based on its record type and
possibly other factors. This is cumbersome, error-prone and inefficient. The
only reason section-agnosticism sorta-kinda works today is because there
aren't very many extensions which apply to AXFR responses. But this is a
moving target we're talking about. You can't expect the rest of the protocol
to stand still.

> answer section.

It doesn't say that they're *not* in the Answer Section, either. We all agree,
don't we?, that the original specification was unclear.

What *is* clear, however, is the general rule that direct answers to
DNS questions are found in the Answer Section of the response. AFAIK, every
client except yours has assumed that, for AXFR as well as non-AXFR responses.
And as far as I can tell, the only reason your AXFR client assumed otherwise
was simply because you happened to code it that way. You didn't start getting
militant about things until it came time to clarify the specification and you
realized that you'd have to change your code. That's the risk you took when
you flouted a basic assumption about DNS response-interpretation that everyone
else has made.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 17 Jul 2001 18:36:57 -0700

To tell the truth, I've never been entirely comfortable with the practice
of using Additional as a kind of "side-channel" for miscellaneous
protocol-extension information. But I think we're already too far down
that path to turn back now, and there's still no good alternative for
incremental extension of the protocol. Nor do I see any reason to treat
AXFR as a special case in this respect. If protocol-extension records can
appear in the Additional Section of responses to regular queries, then
I don't see why they shouldn't be allowed in the Additional Section of
AXFR responses, if the extension is applicable to AXFRs. And the only
reliable way I can think of to allow this, is the "ignore unexpected
RRs" language of the clarify draft.

It also bewilders me somewhat that Dan can *agree* that it's illegal for a
server to *send* zone data in non-Answer sections of an AXFR, but at the
same time argue that an AXFR client can *accept* it there. To be sure, no
client should crash and burn when presented something illegal, but by the
same token I think it stretches "be liberal in what you accept" beyond the
breaking-point to say that it should accept illegal transactions as
*equivalent* to legal ones. I think "ignore" is the appropriate (between
the two extremes) action to take here, when you're talking about something
as mission-critical as DNS. If this sometimes results in a missing chunk
of zone data, that should be quickly detected, the guilty party easily
identified and the software fixed. After all, if a server is so deranged
that it can't even put the zone data into the right section, who knows
what subtle forms of corruption it may have inflicted on the
Answer-Section zone data itself? It's a gamble either way.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 18 Jul 2001 05:47:20 -0700

Andreas Gustafsson writes:
> In other words, neither method of extension is currently safe

But other methods of extension _are_ safe. I have no objections to a new
EXFR query type. All you have to do is make sure that EXFR clients are
compatible with NXDOMAIN/NODATA responses from non-EXFR servers.

(I'm glad you finally fixed this bug in your IXFR clients, by the way.)

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 18 Jul 2001 05:47:49 -0700

Kevin Darcy writes:
> It also bewilders me somewhat

Does it bewilder you that---to take a provocative example---RFC 2821
clearly prohibits SMTP clients from sending non-ASCII header bytes, but
clearly allows SMTP servers to accept those bytes?

> that Dan can *agree* that it's illegal for a
> server to *send* zone data in non-Answer sections of an AXFR,

AXFR server implementors have to stick to the answer section for
interoperability with BIND. Anything else would be a disaster.

> but at the same time argue that an AXFR client can *accept* it there.

That works just fine. There's no interoperability problem.

The TKEY discussion is about certain nonexistent types of TKEY servers
that also wouldn't work with existing caches. Those servers have to be
prohibited, not merely discouraged.

> If protocol-extension records can
> appear in the Additional Section of responses to regular queries,

Unextended caches that obey the RFC 1034, RFC 1035, and RFC 1123 rules,
such as my cache and the BIND 9 cache, will treat those as normal
records. If the protocol extension has a problem with this, as TKEY
does, then the extension is broken.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Jul 2001 05:48:08 -0700

Date:        Tue, 17 Jul 2001 13:19:34 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Could you possibly explain just what it would hurt for the BIND company
  | to alter _their_ implementation to handle data in other sections?

If that was the right thing to do (if there was some advantage to be
gained by doing that), then it wouldn't hurt at all, and I would be
requesting that exactly that happen.

Just now, I can't think of any possible benefit that would gain though,
if data in an AXFR is supposed to be treated just line the data in the
answer section, then it might as well get put in the answer section.
After all, there's nothing to be gained by putting it elsewhere.

The only point for having multiple sections in answers is so the RRs
in those sections can be treated differently, otherwise the different
sections wouldn't exist at all.

  | After all, I might want to deploy an optional AXFR extension that---
  | without wasting space---communicates a few extra bits of information by
  | putting records into AU or AR instead of AN. This extension would be
  | incompatible with current versions of BIND, so BIND has to be fixed!

Yes, if there's any benefit to be gained by that extension, so that it
would ever get general agreement, that would be true.   So, if you can
explain to me just how anyone would ever benefit by deliberately splitting
data that is to be treated just the same over multiple sections, then
perhaps you would get me (and perhaps even someone else) to agree with
you.

On the other hand, it is easy to see how if there was ever some data that
should not be treated the same could easily be marked as different by putting
it in a different section - provided that servers don't go treating the
different sections as if they were equivalent.

  | Now, I realize that there are a million BIND hosts out there, including
  | tens of thousands running ancient versions of BIND, but, gee, surely
  | they'll all upgrade before I deploy my incompatible extension. If they
  | don't, we'll use BIND's ``remote root upgrade'' feature!

Yes, they probably would, if there were to be a reason to do this,
remaining compatible with ancient BIND into the distant future isn't
something to worry about.  Retaining compatability with ancient djbdns
is even less to worry about.

  | Whaddya mean, optional extensions have no right to break compatibility?

I don't mean that, never did.   For sure, the compatability of any
extension needs to be carefully considered to see how well it will
actually work - that's just the same as evaluating whether the rest
of the proposal will actually work.   There's no point defining something
that won't work in practice, no matter what the reason.   But if it
will work, and is generally agreed to be required, then breaking old
stuff can be OK - it's all part of the trade offs to be considered.

  | Maybe you're not swayed by practical compatibility concerns. Well, how
  | about the spirit of RFC 1034? The RFC says that zone transfer messages
  | carry all the zone records. It _doesn't_ say that the records are in the
  | answer section. Obviously clients are meant to read all the sections!

The conclusion does not follow.   More accurate would be "Obviously
clients get the AXFR answer from the answer section, we don't need to
actually say that".

Note that you deliberately avoided answering the question I asked.
>From that I assume that there is no rational reason at all why you
can't change your implementation to only look in the answer section.

Given this, and the notice that you have been given that one day perhaps
an AXFR extension may be created which requires servers to treat the
different sections in an AXFR message differently (and one might assume,
allows servers that don't understand the new stuff to simply ignore it,
by ignoring that section and all its data), then if that ever happens,
and the users of your server all come complaining that they're being forced
to upgrade, and they don't want to (or can't, if your server is no longer
being maintained then) - we'll all just refer them to you, and tell them
that you knew all about this years ago (from that time in the future) and
deliberately decided then to screw them.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Jul 2001 05:48:37 -0700

Date:        Tue, 17 Jul 2001 16:59:04 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The BIND 9 cache saves records from the additional section and provides
  | those records as answers to subsequent queries. Same for the BIND 4
  | cache, the BIND 8 cache, and my cache. Does anyone seriously believe
  | that this is incorrect behavior?

That's an impossible question to answer, how can anyone possibly know
whether anyone else believes that?  So the best that can happen when you
ask a question in that form is to receive silence.

Personally, no, I don't believe it is incorrect to cache records from
auth or additional sections, and return them in later answers, as long
as the AA bit is never set in such an answer.

And, as long as no better answer has been obtained by the server, before
or after.

That is, if you already have an A record received as a direct answer, and
you later get an A record in the additional info section of some reply,
then the first one is the one you should use, not the second (assuming
they're different of course, it makes no difference otherwise - though I
am not convinced that the TTL of the additional info should ever be used
to extend the TTL on an earlier received answer, even given the RR data is
the same).

  | Similarly, if you rip the TKEY support out of BIND 9.1.0, and you put
  | that cache between a spontaneous TKEY server and a TKEY client, you get
  | failures. Does anyone dispute this?

If there are TKEY records being invented (calculated...) and inserted
in the additional section of regular DNS replies, and assuming that
anyone ever actually wants to do a TKEY lookup, then (given the same
caveat about "does anyone" questions), no, that would be a problem.

However, there is no actual problem if either of those two premises
are false - that is, for example, if there's no reason to ever do a
TKEY lookup, that is, if a TKEY is meaningful only when it accompanies
some other data, then there is no actual problem, regardless of
where the odd record might have been cached (the non-understanding
server isn't just going to attach it to some random query for the fun of it,
and there won't be any query for the TKEY itself, so it is relatively 
harmless).

Similarly, in an AXFR, a TKEY in the additional section won't be included
in the zone data, because the zone data is all in the answer section...

  | The inescapable conclusion is that the TKEY extension is broken.

False.

  | It is incompatible with the unextended protocol.

In a way that seems to not matter.

  | It has to be fixed.

At the minute I see no compelling evidence for that.

  | How can
  | anyone use a broken extension as an argument against my AXFR client?

Even in the wildest case, that TKEY was proved to be fundamentally
broken, all it is being used of in that argument is as an example of
something which could also be done in the future.

  | These are fundamental interoperability issues. They have to be settled.

Yes.   That is what the text in axfr-02 is doing.  AXFR clients MUST NOT
treat RRs in the auth and additional sections as part of the zone.

That solves the interoperability problem by defining exactly what is correct.

Then, because we know there are axfr clients written before this was made
clear (one implementation anyway), we do all we can to delay actually
defining anything to put in those sections (or anything that is likely to
be used arbitrarily - tkey is only used by bilateral agreement I think)
until sufficient time has elapsed that older clients are likely to have
been upgraded for other reasons.  And note that AXFR is always a
bi-lateral relationship (any AXFR that matters anyway, nslookup's use of
it for its "ls" command can be ignored) so any use of a protocol extension
can always be avoided by that bilateral relationship if one server cannot
be upgraded for any reason when it would be needed to support the extension.

  | I already gave the obvious example: A records associated to MX records.
  | The A record is helpful---it saves time. You claim that the A is glue;
  | that's rarely true.

Not rarely at all.   There are zillions of domains whose MX records
are aimed at uunet or aol or demon, or similar mail servers.  The A
records that accompany those MX records are glue.   They're not at all
rare...   Now it may be that the server that is answering the query
also happens to be authoritative for the zone that contains the A
record concerned - but there's no way that you can know that when you
receive the reply, unless you go and do an A record lookup, and ignore
the one in the answer, and then determine that it came from the same
servers (which would be useless effort, if you have obtained the A
record from its authoritative servers, then where the glue A record in
the additional section of the MX reply came from is simply irrelevant,
as is its value, you just discard it.)

  | You claim that it's ``to assist the recursing name
  | server in looking up the answer''; that's false.

Andrew's ``looking up'' weren't the right words to use, ``making use of''
would be better.   The use made of them when they accompany NS records
in a referral, is in looking up the original answer.   Other uses are made
of them in other records.  To make use of them it is not necessary to
treat them as if they were the equal of answers.

  | There's no support in RFC 1034, RFC 1035, or RFC 1123 for the notion
  | that additional records are second-class citizens.

I will ignore the "second class" part - both because use of the word "class"
might someday be confusing to someone who equates that somehow with the DNS
zone class mechanism, and because what is first class and what is second isn't
relevant here.

But there's certainly support for treating the data in the different sections
differently - even if it isn't spelled out in words of one syllable.

That is really obvious - if it was all to be treated the same, then there
wouldn't need to be markers (counts) in the packet to separate the RRs
into different groups.   The only explanation for the existence of the
different sections is that the data in them is to be treated differently.

Or perhaps you can find some other explanation for the existence of
the 3 different reply type sections in DNS packets (the question section
is obviously different - the RR data section there is omitted - but by
your "treat it all the same" argument, I guess you should be taking
the RR in the question section of a reply and caching that one as well...)

  | I would have objected to RFC 2181's credibility rules if I had been
  | involved in DNS programming back then. I object to them now as being
  | useless, harmful, and out of line with existing practice.

This is perhaps the best argument I've yet seen .... (sarcasm implied).

What that translates into is "2181 existed when I wrote my implementation.
I decided to ignore it.  Now I claim it shouldn't exist because it isn't
compatible with my implementation".   Or, "I will do what I like, and
everyone else better write/change the specs to reflect what I have done".

This reminds me of just what any "reputable standards organisation" would
do with that line of argument.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 18 Jul 2001 18:59:41 -0700

Robert Elz writes:
> and assuming that anyone ever actually wants to do a TKEY lookup

Please read more carefully. Here's the failure under discussion,
involving a TKEY server, a non-TKEY cache, and a TKEY client:

   (1) the server sends a spontaneous TKEY---apparently this is not
       prohibited by the TKEY spec;

   (2) the cache saves the TKEY record---this is how caches are supposed
       to behave under RFC 1034/1035/1123, and it's how my cache works,
       and it's how the current BIND cache would behave if it didn't
       know about TKEY;

   (3) the client does a * lookup (_not_ a TKEY lookup!)---this is
       something that MTAs do frequently, working around old BIND bugs;

   (4) the cache returns the TKEY record in AN---this, again, is how the
       current BIND cache would behave if it didn't know about TKEY;

   (5) the client sees the TKEY record and chokes---the TKEY spec does
       not allow TKEY in AN.

The non-TKEY cache is behaving properly here. The inescapable conclusion
is that the TKEY extension is broken. The TKEY specification has to be
fixed. It could prevent #1 by prohibiting spontaneous TKEYs, or it could
prevent #5 by requiring that TKEY clients ignore unexpected TKEY
records, or both.

> That solves the interoperability problem by defining exactly what is correct.

Writing specs does not solve interoperability problems. _Deploying code_
can solve interoperability problems. Deployment is, however, expensive.
Why should my users suffer this cost? Why is the BIND company so
amazingly careless with its protocol extensions?

I've seen a lot of bad protocol design in the IETF, but never before
have I seen such blatant disregard for compatibility.

> But if it will work, and is generally agreed to be required, then
> breaking old stuff can be OK

Nobody claims that TKEY is required; in fact, like TSIG, it seems rather
pointless in a world of IPSEC. Nobody claims that the BIND company's
hypothetical AXFR extensions are required. The cost of deploying these
optional features should be paid by the people who want the features.

> The A records that accompany those MX records are glue.

As I said, that's rarely true. The server almost always has the A record
in its authoritative data, if it has it at all. Perhaps you have
forgotten the definition of glue?

  [ in RFC 1034, RFC 1035, RFC 1123 ]
> there's certainly support for treating the data in the different
> sections differently

Certainly. But there's no support for Vixie's credibility rules, or for
your fraudulently labelled ``clarifications'' in RFC 2181.

RFC 1035 requires that new data be preferred to cached data in one
situation. It never requires that cached data be preferred to new data.
It never requires that additional records be kept out of answers.

Your sarcastic comments about my deliberate violation of RFC 2181 (``I
will do what I like, and everyone else better write/change the specs to
reflect what I have done,'' etc.) sound rather stupid in light of the
fact that BIND 9 also deliberately violates RFC 2181.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 18 Jul 2001 18:59:50 -0700

Andreas Gustafsson writes:
> make caching servers ignore rather than cache unknown records
  [ of types 128-255, and then deploy extensions using those types ]

Again, blatant disregard for compatibility.

We already have a mechanism to prevent caching. You simply have to
require (not just recommend) TTL 0.

As for ignoring the record entirely, that's the responsibility of the
extended client. You can, for example, put the server's IP address at
the beginning of the data, and have the client skip the record if the
address doesn't match.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Jul 2001 09:20:22 -0400 (EDT)

Date:        Wed, 18 Jul 2001 18:59:41 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  |    (3) the client does a * lookup (_not_ a TKEY lookup!)---this is
  |        something that MTAs do frequently, working around old BIND bugs;

ANY lookups not directed at an auth server for the zone containing the RR
are close to a waste of time, as all they ever return is what the server
queried happens to have in its cache at the time (unless, sometimes, that
was nothing, and the server queried finds the auth server and does an
ANY query of that).   A query of an AUTH server won't return a TKEY
in the answer section.

But should a client for some odd reason decide that an ANY query of a cache
actually makes sense, then ...

  |    (5) the client sees the TKEY record and chokes---the TKEY spec does
  |        not allow TKEY in AN.

"chokes" in any reasonable implementation will be "ignores the record".
In practice, those applications that do do ANY queries, are looking for
a couple of particular record types (they'd often rather be sending a
query for A AAAA A6 MX and CNAME but can't currently do that in one
message) anything else returned (NS, SOA, RP, LOC, HINFO, WKS, ...) just
gets ignored anyway - it is kind of hard to see why TKEY is going to
be treated differently.

  | or it could
  | prevent #5 by requiring that TKEY clients ignore unexpected TKEY
  | records,

Yes, the TKEY spec probably should do that, but that it doesn't doesn't
make it fatally flawed, just not as complete as it could be - something
to fix when it is revised.

  | Writing specs does not solve interoperability problems. _Deploying code_
  | can solve interoperability problems. Deployment is, however, expensive.

Yes, which is why it is good if everyone can agree on what the deployed
code should do to void the problem before anyone starts deploying anything.
Otherwise the attempts to solve the problems can just cause other problems.
That is, writing the specs is a useful first step.

  | Why should my users suffer this cost?

We're not back at this again are we?  I thought this had already been
made clear ... no-one is asking your users to do anything.  We're
suggesting that you should change your implementation and then make
that available to your users if they want it.   You can even delay
making the changed version available until there are other updates to
the code for other reasons if you like (no need to actually go do the
work of making a distribution just for this).   Just make the change
in your master sources (it doesn't even need any real doc, since it
is changing nothing anyone will ever notice) and then let natural
selection play its part.

You have yet to explain what is difficult/hard/impossible/unreasonable
about that.   I seem to recall that people who have seen your code have
even demonstrated the change that needs to be made...

  | As I said, that's rarely true. The server almost always has the A record
  | in its authoritative data, if it has it at all. Perhaps you have
  | forgotten the definition of glue?

No.   As I said, the server will often be authoritative for the A record
involved (not always, but often), and so the A record didn't come from
glue in the server's data.   But the resolver that receives the reply has
no way to know that - all it sees is an A record that isn't from the same
zone as the answer.   That's glue.   There's no way at all for the resolver
to know whether the server was authoritative or not.

  | Certainly. But there's no support for Vixie's credibility rules, or for
  | your fraudulently labelled ``clarifications'' in RFC 2181.

No question but what started out as clarifications also grew some new
specifications (as I recall it, 2181 even makes that clear, despite the
title still saying clarifications).

So?

Call this part "corrections" if you like.

  | Your sarcastic comments about my deliberate violation of RFC 2181
  | [...] sound rather stupid in light of the
  | fact that BIND 9 also deliberately violates RFC 2181.

No, it isn't that your server violates 2181 that I commented on.
Nor do I care much whether BIND9 does (nor whether the two of them
ignore the same part).   When 2181 gets considered for elevation to DS
it will get reviewed, and any parts of it that are generally considered
to be wrong will either get deleted, or corrected.   That's a normal
part of our iterative standards development process.

What was ludicrous in your statement was the suggestion that the deployed
base that you created by deliberately ignoring 2181 was, in itself,
a reason for 2181 to be changed.

This seems to be based on your flawed assumption that all the IETF does is
document that which exists in the wild.   That's not true - what we do
is document what should exist out there, as best we can judge it.  That is
heavily influenced by what actually is out there of course - on the
assumption that we wouldn't be shipping stuff if we didn't believe it was
the right thing - but not always.

eg: back in the distant past, old BINDs implemented the SOA.serial
field as a (perhaps signed, I forget) integer, with a range from 0
to 2^32-1 (or -2^31 .. 2^31-1 if it was signed).   Upon reaching the
max value it simply stopped.   And the 0 was "magic" (may still be
in BIND8, though I hope that is fixed in BIND9).   Back then, BIND
was essentially the whole deployed base.   According to your theory
on what the IETF should do, it should have simply documented the
serial number as a simple bounded integer value, to match what was
actually deployed.   But that would have been stupid - not a rational
definition of the field, instead, the (almost) whole deployed base
was simply made to fix the bug, and now we have serial numbers
everywhere that actually work the way they were designed to work.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: Thu, 19 Jul 2001 18:57:39 -0700

> "chokes" in any reasonable implementation will be "ignores the record".

That's not what Wellington told us. ``There would be a problem if a
client was sanity checking the response,'' he said.

I agree that this potential compatibility problem disappears if TKEY
clients ignore unexpected records. Guess what? That also eliminates the
potential compatibility problems with AXFR!

> about that.

The benefits are nonexistent. The harms include encouraging further
disregard for compatibility. What stops incompetent implementors from
demanding another code change every week? Ignore AXFR AR, discard TKEY,
ignore types 128-255, recognize IXFR, ignore MS garbage. This is not a
sane way to handle optional protocol extensions.

> What was ludicrous in your statement was the suggestion that the
> deployed base that you created by deliberately ignoring 2181 was, in
> itself, a reason for 2181 to be changed.

Huh? I explicitly pointed out an important violation of RFC 2181 by

   * the BIND 4 cache,
   * the BIND 8 cache,
   * the BIND 9 cache, and
   * my cache.

Later I objected to RFC 2181 as being useless, harmful, and out of line
with existing practice. Where did you get the idea that I was talking
about only my cache?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 20 Jul 2001 05:45:01 -0700

Date:        Thu, 19 Jul 2001 18:57:39 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I agree that this potential compatibility problem disappears if TKEY
  | clients ignore unexpected records. Guess what? That also eliminates the
  | potential compatibility problems with AXFR!

Yes, exactly, this is what we have been trying to tell you - just ignore
unexpected records (anything at all in the auth or additional sections)
and potential compatibility problems will be eliminated.

Glad you have finally conceded the point.

  | What stops incompetent implementors from
  | demanding another code change every week?

Because the community as a whole will react negatively.   Here the
community as a whole is telling you this is a good thing to do, and
in fact, this was what was always intended that you should do - it
is just that the doc didn't say that as well as it should, it just
assumed that readers would be able to infer it.   It is quite correct
to point out that the doc wasn't clear - and the solution to that is
to clarify it.

  | Huh? I explicitly pointed out an important violation of RFC 2181 by
  | 
  |    * the BIND 4 cache,

Yes, it was what it had been doing, that everyone conceded was incorrect
and harming the internet - it was to document a better scheme (and knowingly
a new scheme) that those rules were created (after quite a bit of
discussion).   That's what the WG agreed that servers (not having dnssec
yet available to them) should be doing to improve things.   No-one was
pretending that it was current practice.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: Sat, 21 Jul 2001 00:31:16 -0700

Robert Elz writes:
> Yes, exactly, this is what we have been trying to tell you - just
> ignore unexpected records

I'm going to try one last time to explain this.

We're talking about a failure that can happen when you combine
TKEY-extended clients, TKEY-extended servers, and unextended caches.

We're also talking about a solution, in which THE TKEY CLIENTS ignore
unexpected records. This is a good solution, preserving compatibility
with the unextended protocol in a straightforward way.

This does not mean that THE UNEXTENDED CACHES ignore unexpected records.
That would be a thoroughly irresponsible solution, forcing the installed
base to upgrade for the sake of an optional protocol extension.

I cannot imagine how you interpreted ``TKEY clients ignore unexpected
records'' as ``unextended caches ignore unexpected records.''

The reason this discussion started is that the same failure can happen
when you combine TKEY-extended clients, TKEY-extended servers, and my
AXFR client. (My AXFR client, just like my cache and the BIND cache,
saves AU/AR records.) Guess what? If THE TKEY CLIENTS ignore unexpected
records, this problem disappears too!

> Glad you have finally conceded the point.

I find it difficult to believe that you're this stupid.

> Here the community as a whole is telling you

``The community as a whole''? Looks like a standards committee packed
with representatives of one vendor and users of that vendor's products.
The committee has a long history of labelling protocols as ``standards''
if, and only if, that vendor plans to implement them.

---Dan