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.''

---

From: [email-masked]
Date: Wed, 04 Dec 2002 13:53:27 +1100

> whom the zone owner wants to have as a secondary.''

	No is a secondary.  It may not be able to get the contents
	of the zone but it is a secondary.  It is performing as
	many parts of the protocol as it can as a secondary up until
	it gets a copy of the zone when it can actually start serving
	data.  Those parts of the protocol are to request a AXFR and
	to keep requesting AXFR's until told otherwise.

	Mark

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 4 Dec 2002 17:09:09 +0100 (CET)

On Tue, 3 Dec 2002, Kevin Darcy wrote in reply to DJBDNS implementor
Bernstein:

[long lines wordwrapped]

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

I've been trying to work out why any person would consider TCP FIN to be
used to terminate a connection due to query type (AXFR); and as near as I
can figure, that design choice of djbdns stems from a paragraph in 4.2.2
(TCP usage) of 1035, which states (as part of suggested TCP connection
management policies):

   - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful
     close.

Unfortunately, the language used in this paragraph is imprecise, and the
paragraph can (has) lead to multiple interpretations.  It should be
clarified (hence a need for a clarification draft).

I presume that Bernstein's interpretation of that paragraph in writing
djbdns was something like:

	TCP Connections can be closed by the server after the connection
	has been idle for a period, eg two minutes.

	TCP Connections should allow multiple queries, eg SOA and AXFR on
	the same connection.

	If the server cannot answer a query (eg, has been configured not
	to do an AXFR of a zone to that particular client IP address), the
	connection may be immediately closed instead of gracefully.

If my presumption is correct, Bernstein (and any other implementors who
have taken the same course of arbitarily closing a connection due to local
AXFR policy) have failed to read the rest of the 1034/1035 document set,
and the meaning of the response code 'Refused' (1035, 4.1.1):

	Refused - The name server refuses to perform the specified
	operation for policy reasons.  For example, a name server may not
	wish to provide the information to the particular requester, or a
	name server may not wish to perform a particular operation (e.g.,
	zone transfer) for particular data.

Another thing that such implementors have ignored is the following
paragraph in 1034 4.3.5:

	When the poll shows that the zone has changed, then the secondary
	server must request a zone transfer via an AXFR request for the
	zone.  The AXFR may cause an error, such as refused, but normally
	is answered by a sequence of response messages.  The first and
	last messages must contain the data for the top authoritative node
	of the zone.

My, rather obvious, interpretation of the above paragraph is:

	( If you are using AXFR to transfer zones, )
	When the poll made by the secondary shows that the zone has
	changed, then the secondary must request a zone transfer via an
	AXFR request for the zone.

	When making the AXFR request to an authoritative master, the
	response received by the secondary can be _one_ _of_:

		Error (eg, refused).
	or
		A sequence of response messages.

( Note lack of 'Closed Connection' as a possible response )

--==--
Bruce.

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