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