Subject: Re: axfr-clarify supporting unauthorized users

From: [email-masked]
Date: Mon, 02 Dec 2002 14:49:28 +1100

> Have you stopped beating your wife, Mark?

	Dan, I demand a apology for this remark.
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Mon, 02 Dec 2002 14:58:21 +1100

> [email-masked] writes:
> > "Does your server meet RFC 1034 and return REFUSED under these conditions?"
> 
> It is entirely up to the primary to decide who the secondaries are. RFC
> 1034 imposes no constraints on this decision. A non-secondary asking for
> AXFR is violating the protocol (specifically, the text that you quoted),
> and has no right to a response.

	Dan I asked you a reasonable question with reasonable pre-conditions.
	This does not answer that question.
 
> > I suspect that the DNS admistators of most ISP curse your stupid decision
> > when trying to setup secondary service for one of their customers who
> > is using your servers but forgot to adjust the access controls.
> 
> Funny how nobody has ever complained about that.

	Whether they have complained to you or not is irrelevent.
 
> Maybe this is because step 3 of my upgrade-from-BIND instructions tells
> people to authorize zone transfers from their third-party servers. Or
> maybe it's because nobody actually gives a damn whether the AXFR client
> prints useless error message #1 or useless error message #2---all the
> useful information is on the server side.

	Well if people didn't give a damn we wouldn't be having this
	discussion.

> Next, I suppose, you're going to demand that everybody have BIND-style
> promiscuous defaults, so that users who ``forgot to adjust the access
> controls'' don't have to be bothered fixing their configurations.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 2002 20:34:43 -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. ]

> Dan I asked you a reasonable question with reasonable pre-conditions.

No, you didn't. Your preconditions contradict themselves. You start from
the silly assumption that an unauthorized user, a user to whom the
primary refuses to give the zone, can nevertheless be a secondary, and
then you complain that the primary isn't doing what you think it's
supposed to be doing for a secondary.

Maybe your implementation has some sort of ``unauthorized users who we
call secondaries even though they're not'' list, but there's nothing in
the protocol requiring this.

---

From: [email-masked]
Date: Wed, 04 Dec 2002 10:18:41 +1100

> supposed to be doing for a secondary.

	No.  You asked that we restrict the discussion to secondaries.
	I did restrict the discussion to secondaries.  Humans, not
	software, decide who is and is not a secondary.  I rephrased
	the question in terms of the humans deciding that a machine
	should be secondary and should transfer from the primary and
	the primary not being updated to reflect that decision.

	Now does your server return REFUSED under those conditions or
	not?

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 03 Dec 2002 18:35:21 -0500

> the protocol requiring this.

Dan,
        RFC 1034 only mentions two possible outcomes of an AXFR request: "an
error, such as refused" or an answer consisting of "a sequence of response
messages", i.e. a zone transfer. Now, we all realize that circumstances beyond
the control of the DNS implementation may cause the connection attempt to fail
(network congestion, hardware errors, OS crash, whatever), or to be prematurely
broken, but RFC 1034, as a *DNS* spec, describes what a DNS implementation should
do (or attempt to do), and TCP FIN is not among the options here. Surely you can
see this, can't you?

Now, you can perform as much semantic acrobatics as you wish over whether that
paragraph only applies to "secondary servers" or not, but the fact that
"refused" is mentioned as a legitimate response to an AXFR request from "a
secondary server", combined with the fact that the companion RFC describes the
"refused" RCODE as "the name server refuses to perform the specified operation
for policy reasons" means that it is illogical to limit the definition of
"secondary server" to "only those entities which, by policy, are allowed to
request and/or receive zone transfers from me". To put it another way, the
definition of "secondary server" which you are proposing ineluctably leads to the
conclusion that "refused" could *never* be a valid, standards-conforming response
to an AXFR request. Yet clearly this line of thought is at odds with the RFC 1034
verbiage to which Mark refers.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2002 01:24:05 -0000

[email-masked] writes:
> Humans, not software, decide who is and is not a secondary.

No. The secondaries are defined by software. Humans may decide who they
_want_ to have as secondaries, but those servers are _not_ secondaries
until the software on both sides is configured appropriately.

The paragraph you quoted says ``secondary.'' It does not say ``anyone
whom the zone owner wants to have as a secondary.''