Mark(_dot_)Andrews(_at_)isc(_dot_)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(_at_)ops(_dot_)ietf(_dot_)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(_dot_)Andrews(_at_)isc(_dot_)org