Subject: Re: axfr-clarify supporting unauthorized users

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

[email-masked] wrote:

>>"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-informat
>>ive
>>*today*, at least it's more informative than TCP FIN, and also, it has room t
>>o
>>grow to be more informative in potential revisions of the DNS protocol. Somet
>>hing
>>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 create
>>d
>>dedicated to error reporting. TCP FIN forecloses such possibilities and is
>>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.
>  
>
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

--
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: Wed, 04 Dec 2002 13:53:27 +1100

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

	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

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

---

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.