Subject: objection to axfr-clarify

From: Aaron Swartz <[email-masked]>
Date: Sun, 24 Nov 2002 10:43:21 -0600

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Kandra Nygårds <[email-masked]>
Date: Sun, 24 Nov 2002 20:09:24 +0100

This is unsurprisingly similar to the exact statements of a certain DNS
server author, but I'll reply to it as if it's Mr Swartz own opinions.

From: "Aaron Swartz" <[email-masked]>

> server and djbdns's axfrdns server.

What's more logical?

Client asks for data. Server responds with "Ok." and sends nothing.

Client asks for data. Server responds with "Not allowed" and sends nothing.

Client asks for data. Server doesn't respond whatsoever.

Just because one or more implementations doesn't follow common courtesy
doesn't mean that everyone should do the same.

> interoperability and appears to prohibit the behavior of djbdns's

Client asks for data. Server responds with "Whoa! Danger! Danger!" and sends
something that might or might not resemble a zone.

Just because DJB doesn't bother to make this trivial check doesn't mean that
it's the best way to go.

> behavior of djbdns's axfr-get client.

Once again, just because one implementation doesn't do this doesn't mean
it's not the best way to go.

> additional section." Ditto.

Ditto.

> this should be specified in terms of protocol behavior, not user

Finally you point out an actual issue. While I haven't seen the UltraDNS
server, I assume that it too has some kind of mechanism for loading RRs into
its database. I also assume that it has some kind of mechanism for
separating RRs into various zones. This is what this quote is refering to.
The fact that DJBDNS doesn't use BIND-style zonefiles doesn't matter, since
the section specifies "or by some other, equivalent method for configuring
zone data"

Now, besides the last section, do you have any actual operational arguments
for objecting to the draft, besides objecting to it because two of the
implementations you use don't follow it?

Best regards,
Kandra Nygards