objection to axfr-clarify

[Aaron Swartz <me@aaronsw.com>]

Hi. As a user of the UltraDNS server and client, the BIND server, and 
the djbdns server and client, I have a strong interest in AXFR 
interoperability. I object to the publication of axfr-clarify on the 
grounds that it imposes requirements not necessary for 
interoperability, in violation of RFC 2119 (BCP 14), section 6. I also 
object on the grounds that it outlaws the behavior of deployed tools 
which I use. Major changes to the protocol like these should not be put 
into a document that supposedly "clarifies [...] the original AXFR 
protocol".

Specifically, in 
http://users.starpower.net/ogud/draft-ietf-dnsext-axfr-clarify-04.txt I 
found the following issues:

Section 3: "If the master server is unable or unwilling to provide a 
zone transfer, it MUST respond with a single DNS message containing an 
appropriate RCODE other than NOERROR." This is not required for 
interoperability and appears to prohibit the behavior of the UltraDNS 
server and djbdns's axfrdns server.

Section 3.1: "MUST check the RCODE in each message and abort the 
transfer if it is not NOERROR." This is not required for 
interoperability and appears to prohibit the behavior of djbdns's 
axfr-get client.

Section 3.5: "Slaves MUST ignore any authority section contents they 
may receive from masters that do not comply with this requirement." 
This is not required for interoperability and appears to prohibit the 
behavior of djbdns's axfr-get client.

Section 3.6: "The slave MUST ignore any unexpected RRs in the 
additional section." Ditto.

Section 4: "An RR is associated with a zone by being loaded from the 
master file of that zone at the primary master server, or by some 
other, equivalent method for configuring zone data." This is unclear. 
Neither djbdns's axfrdns server nor the UltraDNS server have a notion 
of "master files" or "zone data". This and the requirements based on 
this should be specified in terms of protocol behavior, not user 
interface.

I did not do a full review of the BIND, UltraDNS, or djbdns 
implementations. There are likely more requirements that are violated 
by these popular implementations than I have noted here. I'd be happy 
to help someone who wants to do a more detailed review of the UltraDNS 
implementation.

--
Aaron Swartz [http://www.aaronsw.com]


--
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/>