Re: axfr-clarify's fraudulent claims of consensus

[Mark.Andrews@isc.org]

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

	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.
 
> (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.)

	I never said that Microsoft was the responible vendor.  I've
	never bothered to find the name of the vendor.
 
> > There is different behaviour.  That is enough reason in and
> > 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.

	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.
 
> > I don't think anyone envisioned someone that would process
> > 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.

	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.

> (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.

	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
 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org