Re: axfr-clarify supporting unauthorized users

[Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>]

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.


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>