Re: axfr-clarify's fraudulent claims of consensus

[Mark.Andrews@isc.org]

> 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: Mark.Andrews@isc.org