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
while there are records left in the answer section
read a record
Let me see if I have your logic right,
Read the number of questions then skip them. Read three
numbers, add them up, then read this number of records.
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: