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

---

From: Aaron Swartz <[email-masked]>
Date: Sun, 24 Nov 2002 14:11:00 -0600

Hi, Kandra. Thanks for your response.

> What's more logical?

We can discuss what's more logical, but that's not the point. The 
document claims that in it "the existing practice has been codified in 
the interest of interoperability". This is obviously false. The vast 
majority of implementations do not do it this way (notably BIND8, 
djbdns and UltraDNS) and I've only heard reports that one does (BIND9). 
How can the actions of only one, recent application be the existing 
protocol? If I created a new piece of software, that sent email to 
[email-masked] whenever an unauthorized client connected, 
would the WG clarify the protocol to require that behavior?

Even if the majority of deployed code *did* do things this way, 
RFC2119, a best current practice and a normative reference of this 
draft, expressly prohibits making requirements which are not necessary 
for interoperability. I haven't heard anyone explain why these are 
necessary for interoperability.

Even if this *wasn't* a requirement, I've heard reasonable arguments 
for why a server wouldn't want to explain to unauthorized clients why 
they're unauthorized. Of course, that is not the issue here.

Passing off what you feel as "better" or "more logical" as "the 
existing practice" when:
1. it clearly is not;
2. is not necessary for interoperability, in violation of a best 
current practice; and
3. is arguably not the consensus of the working group;
seems highly misleading at best and downright dishonest at worst.

My objections would be easily resolved if:
  - the draft suggested future implementations do these things;
  - the draft recommended current implementations be upgraded; or
  - the draft specified a new protocol on a different port;
but it doesn't any of those.

> doesn't mean that everyone should do the same.

Just because one or more implementations does provide a response 
doesn't mean that everyone should be required to do the same.

> the section specifies "or by some other, equivalent method for 

It's completely unclear to me what to do in such a case. Is the djbdns 
method equivalent? I doubt it, since it has no system of specifying 
what's in what zone. But let's give you the benefit of the doubt and 
look at the actual requirements.

"the master MUST send exactly those records that are associated with 
the zone" How am I supposed to calculate which are associated?

"The slave MUST associate the RRs received in a zone transfer [...] and 
maintain that association" How am I supposed to associate them if my 
format has no provision for it?

Why can't the draft explain the actual protocol behavior it wants?

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

You imply that those aren't "actual operational arguments". This 
clarification will lead future implementors to believe this is deployed 
practice (when as I've show it clearly is not), causing 
interoperability failure. That is not acceptable.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 25 Nov 2002 15:23:59 -0800 (PST)

Aaron Swartz writes:
> the interest of interoperability". This is obviously false.

You are quoting the draft out of context.  It says:

   Where the text in RFC1034
   conflicts with existing practice, the existing practice has been
   codified in the interest of interoperability.

The only part of the draft that claims there is a conflict between
RFC1034 and existing practice is the first two sentences of section 5,
"transmission order".  The text you quoted is intended as a reference
specifically to that part.  If this is unclear, I will be happy to
change the text to make the reference to section 5 explicit.

> The vast 
> protocol?

You are incorrect regarding both BIND 8 and UltraDNS - they both
"respond with a single DNS message containing an appropriate RCODE
other than NOERROR" as the draft specifies.  I didn't dare try to run
BIND 4.8.3, but inspection of the code suggests that it does the same
thing, meaning this behavior is established practice at least since
1990.

> necessary for interoperability.

Although you are correct in that requiring a response to be sent in an
error case is not necessary for interoperability in the sense of being
able to successfully complete a zone transfer, it is necessary in
order to have an interoperable means of indicating the reason for
failure.

This text was discussed at length on namedroppers in April 2001 and I
believe the current text reflects the rough consensus of the working
group at that time.  At one time during that discussion I proposed
changing the MUST to a SHOULD, but Robert Elz specifically requested
that I retain the MUST.

As for the other issue you raised, I thought this had already been
adequately covered by my response to DJB's message, but here we go
anyway...

> the zone" How am I supposed to calculate which are associated?

If you received the zone by AXFR, it's what you received in that AXFR
(as opposed to what you received in AXFRs of other zones).  If you are
the primary master and load from a master file, it's what you loaded
from that master file (as opposed to other master files).  If you are
the primary master and using some other configuration method, it's
entirely up to you how you define the association; the point is that
you must be able to unambigously say which records are part of which
zone (or zones, in the case of a djbdns-like mechanism where a record
can be configured into two zones at once) for the purpose of outgoing
transfers.

> format has no provision for it?

What do you mean by "your format"?  A file format?  If your server
stores the data from incoming zone transfers in files, then it must
either store each zone in a separate file, or if they are stored in a
common file, the file format must have a provision for keeping the
data separate.

> Why can't the draft explain the actual protocol behavior it wants?

It is trying to.  The use of the term "associated with" may be a bit
confusing, but previous attempts at phrasing it using more common
terms like "the records of a zone" or "in a zone" were objected to on
the basis that there were existing, conflicting definitions of those
terms based on the viewpoint of the resolver rather than the server;
e.g., a resolver may consider an NS record to be "in" a child zone
even though it was received from a parent server that loaded it from
the master file of the parent zone.  Suggestions for clearer
terminology are welcome.
-- 
Andreas Gustafsson, [email-masked]