Subject: Re: axfr-clarify supporting unauthorized users

From: Kevin Darcy <[email-masked]>
Date: Mon, 02 Dec 2002 12:46:36 -0500

"D. J. Bernstein" wrote:

> [email-masked] writes:
>
> > > Of course, there's also no support in RFC 1034 for your strange claim
> > > that a closed connection is not ``an error.''
> > Closing a connection is not sending back a error message.
>
> On the contrary. I agree that FIN is, in this context, not a
> particularly _informative_ error message, but REFUSED and SERVFAIL
> aren't particularly informative either; they carry only marginally more
> information than FIN.

I'd just like to point out that, even if RCODE=REFUSED is rather non-informative
*today*, at least it's more informative than TCP FIN, and also, it has room to
grow to be more informative in potential revisions of the DNS protocol. Something
could be put in an OPT record, for instance, detailing the error condition
further, extended flags could be used, or a whole new RR type could be created
dedicated to error reporting. TCP FIN forecloses such possibilities and is
basically an evolutionary dead-end for the protocol.

- Kevin

--
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: [email-masked]
Date: Tue, 03 Dec 2002 09:07:03 +1100

> basically an evolutionary dead-end for the protocol.

	It's already happened.  NOTAUTH is returned when the server
	is not configured for the zone rather than REFUSED from the
	RFC 1034 days.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 02 Dec 2002 17:12:51 -0500

>	is not configured for the zone rather than REFUSED from the
Indeed. In fact, I think I was one of the ones who urged that provision 
several discussion rounds ago.

I guess memory is the first thing to go...

                                        - Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 2002 21:00:02 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  your subscription address is
  [email-masked], please post from it or, if you
  wish to regularly post from an address that is not subscribed to this
  mailing list, send a message to [email-masked] and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

Kevin Darcy writes:
> Something could be put in an OPT record, for instance, detailing the
> error condition further, extended flags could be used, or a whole new
> RR type could be created dedicated to error reporting.

And, once these error-message extensions were added to the protocol,
would we then have nitwits claiming that all the servers saying REFUSED
were suddenly non-compliant because ``making it easier to detect common
misconfigurations is an important aspect of interoperability''?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 03 Dec 2002 17:34:53 -0500

> misconfigurations is an important aspect of interoperability''?

No, RCODE=REFUSED would still be a valid response for the foreseeable future, but
these other, richer error-reporting mechanisms would be preferred. RCODE=REFUSED
is *already* documented in the relevant DNS specifications; TCP FIN in response
to an AXFR request is *not* and does not need to be grandfathered.

- Kevin

---

From: Greg Hudson <[email-masked]>
Date: Tue, 3 Dec 2002 19:46:32 -0500

Dan Bernstein wrote:
> would we then have nitwits claiming that all the servers saying
> REFUSED were suddenly non-compliant because ``making it easier to
> detect common misconfigurations is an important aspect of
> interoperability''?

You objected to this clause of axfr-clarify on two grounds:

  (1) It forbids the behavior of djbdns, which you believe to be
      compliant with the existing (pre-clarification) specifications,
      and

  (2) It's not necessary for interoperability, and therefore should
      not be a MUST.

I disagreed with (2) on the grounds that interoperability is about
more than just the case where everything is working.  That particular
argument had no bearing on (1).  So no matter how slippery the slope,
my argument would never imply that conforming implementations of an
old standard would magically become non-conforming when a revision is
published.  (A conforming C89 compiler remains a conforming C89
compiler even if it is not a conforming C99 compiler.)

(As a separate point, I agree with other people that a TCP FIN was not
a reasonable implementation choice given the text in RFC 1034 and
1035, and thus djbdns's behavior here should not be considered a data
point for a clarification effort.  That argument bears on (1) but not
(2).)

I do not know of an IETF policy on ad hominem remarks, but perhaps it
should be discouraged for working group chairs to consider arguments
intermixed with personal slurs when gauging consensus.  That would
allow contributors to ignore abusive behavior such as Dan's without
worrying that doing so might affect the standards process.