Subject: Re: axfr-clarify's fraudulent claims of consensus

From: [email-masked]
Date: Thu, 20 Feb 2003 00:38:12 +1100

> Josh Littlefield writes:
> > RFC1034 clearly states that the answer section "carries RRs which
> > directly answer the query."  I don't see how anyone could conclude
> > that AXFR clients should look for zone RRs anywhere else.
> 
> There is overwhelming consensus that (in the absence of extended
> behavior requested by the client) the AXFR _server_ must leave the
> additional section and authority section empty. It must put the data
> into the answer section. All existing servers work this way---and must
> do so for interoperability.
> 
> There are several perfectly valid parsing strategies for the client.
> In particular, my software uses the simple strategy
> 
>    while there are records left
>       read a record

	Which can only be found by adding up the three fields in
	the header (number of answer  records (which bind uses),
	number of records in the authority section and number of
	records in the additional section).  You can't use the DNS
	message length as too many implementations get it wrong and
	leave a couple of bytes between the end of the messages as
	discovered by processing the records and the end of the
	data that is read.  You have discovered this havn't you?
 
> while BIND 9 uses the slightly more complicated strategy

	BIND has always used the simple strategy of reading the
	number from the header then processing that number of
	records after skipping any questions, again read from
	the header.
 
>    while there are records left in the answer section
>       read a record

	Let me see if I have your logic right,
	
	Simple:
	Read the number of questions then skip them. Read three
	numbers, add them up, then read this number of records.
	
	Complicated:
	Read the number of questions then skip them. Read one
	number then read this number of records.

	I think you have the labels the wrong way around.

> Both strategies work, since servers put all records into the answer
> section. Neither strategy creates any interoperability problems.

	There is different behaviour.  That is enough reason in and
	of itself to clarify the issue.

	I don't think anyone envisioned someone that would process
	records outside of the answer section as answers.

> There is certainly _not_ consensus on telling the _client_ to use the
> BIND 9 strategy. Furthermore, any such statement (whether ``MUST'' or
> ``SHOULD'') would blatantly violate RFC 2119, section 6.
> 
> This is about the tenth time that I have had to point out the blazingly
> obvious fact that constraining _server_ behavior is not the same as
> constraining _client_ behavior.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 17:50:37 -0000

[email-masked] writes:
> You can't use the DNS message length as too many implementations get
> it wrong and leave a couple of bytes between the end of the messages
> as discovered by processing the records and the end of the data that
> is read.

False. The Microsoft AXFR _client_ puts two extra bytes after its AXFR
requests to indicate its support for multiple records per DNS packet,
but the Microsoft AXFR _server_ does nothing of the sort. My AXFR client
can and does use the packet length, in full compliance with RFC 1035.
There are no interoperability problems here.

(By the way, my DNS software is more widely deployed than Microsoft's,
and much more stable, so if there were an interoperability problem then
the lowest-cost solution would be to redeploy Microsoft's software. But
these problems are a figment of your imagination.)

> of itself to clarify the issue.

False premise, bad logic, false conclusion. These software differences
don't affect interoperability, so they are none of the IETF's business.
See RFC 2119, section 6.

> records outside of the answer section as answers.

Read the full DNS standards, RFC 1034 and RFC 1035. Example: To save
time, the additional section of an MX response usually contains A
records that are reported as answers to subsequent queries. This is
perfectly standard behavior not only in theory but also in practice.

(To the extent that proposed standard RFC 2181 suggests otherwise, RFC
2181 is out of whack with reality, and RFC 2181 will have to be fixed.)

You can't seriously promote a ``never treat additional records as
answers'' religion when every major DNS cache---including BIND 9---
blatantly violates that religion. If you start adding qualifiers such as
``except in MX queries'' then your religion starts to sound really dumb.

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

---

From: Kandra Nygårds <[email-masked]>
Date: Wed, 19 Feb 2003 21:14:49 +0100

From: "D. J. Bernstein" <[email-masked]>

> perfectly standard behavior not only in theory but also in practice.

The query is for MX. The answer section contains MX, which is correct. The
response usually contains one or more A records in the additional section,
which are NOT part of the answer but served as additional data as a
convinience.

A query for AXFR would similarily contain the response to the query in the
answer section. As a convenience, servers might add additional data in the
additional section, but those are NOT part of the answer and should not be
treated as such.

Easy enough for you to understand?

- Kandra

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

---

From: [email-masked]
Date: Thu, 20 Feb 2003 08:28:38 +1100

> There are no interoperability problems here.

	Well you havn't struck the servers that get this calculation
	wrong yet.  However I don't find that suprising as your server
	really isn't designed to with AXFR in mind.
 
> these problems are a figment of your imagination.)

	I never said that Microsoft was the responible vendor.  I've
	never bothered to find the name of the vendor.
 
> don't affect interoperability, so they are none of the IETF's business.

	But it does affect interopability with servers that get
	things slightly wrong.

	You can't trust the UDP length and you can't trust the TCP
	message size to find the end of reply received.  There are
	servers that get these calculations wrong.
 
> perfectly standard behavior not only in theory but also in practice.

	The additional section does NOT contain the answer.  It
	contains other data that may be related however it is not
	part of the answer to the question an is not treated as
	such.

> ``except in MX queries'' then your religion starts to sound really dumb.

	We selectively cache the contents of the additional section.
	We also reject what shouldn't be there or what we don't
	trust the current server to give us.

	Mark