Re: axfr-clarify supporting unauthorized users

[Mark.Andrews@isc.org]

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or
>   fix subscription your subscription address! ]
> 
> Mark.Andrews@isc.org writes:
>   [ quoting RFC 1034 ]
> > 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
> 
> See how this starts by saying that the SECONDARY SERVER does something?
> You are not the secondary server. You have no authorization to even ask
> for AXFR, let alone demand an answer.

	So.  Do you claim that your server returns REFUSED to a
	server that is *supposed* to be a SECONDARY when the PRIMARY
	is misconfigured?  If it doesn't it would appear to be in
	violation of RFC 1034.
	
> 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.
	It is just "closing a connection".  The caller has know
	knowledge of why the connection failed.
 
> (As an engineering matter, every protocol has to allow connections to be
> closed. Even when limiting unauthorized resource use isn't an issue,
> hosts can and do crash. Forbidding this would be idiotic.)
	
	We are not forbidding it.  RFC 1035 says that the client should
	initiate the closure.  The server should only do it in the face
	of resourse starvation or when the connection has been idle for
	several minutes.

	Having the server close the connection immediately on reciept of
	a AXFR request doesn't meet these conditions.

	Client initiation is better for most IP stacks.  The client can't
	initiate closure unless it is told that it in not going to get
	a AXFR.

	Follow the protocol.  Let the client initiate the closure.

RFC 1035

4.2.2. TCP usage

Messages sent over TCP connections use server port 53 (decimal).  The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field.  This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.

Several connection management policies are recommended:

   - The server should not block other activities waiting for TCP
     data.

   - The server should support multiple connections.

   - The server should assume that the client will initiate
     connection closing, and should delay closing its end of the
     connection until all outstanding client requests have been
     satisfied.

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

> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> 
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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