Subject: Re: axfr-clarify supporting unauthorized users

From: [email-masked]
Date: Fri, 29 Nov 2002 14:15:17 +1100

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   [email-masked], please post from it or
>   fix subscription your subscription address! ]
> 
> [email-masked] 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 [email-masked] 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: [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: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 18:03:39 -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. ]

[email-masked] writes:
> Do you claim that your server returns REFUSED to a server that is
> *supposed* to be a SECONDARY when the PRIMARY is misconfigured?

RFC 1034 says ``secondary server,'' not ``any clueless twit who _thinks_
he's a secondary server.'' The list of clients authorized to ask a
server for zone transfers is entirely up to the server. (As you know,
this list is generally _not_ the same as the NS list published in DNS.)

> 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. Anyone who doesn't understand why his AXFR attempt
was rejected will have to ask the server administrator.

Anyway, as an unauthorized user, you have no right to ask for AXFR in
the first place, let alone demand an answer, let alone demand an
_informative_ answer.

  [ quoting RFC 1035 ]
> Several connection management policies are recommended:
  [ ... ]
> 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.

This doesn't say that servers should be polite to attackers trying to
grab AXFR results without authorization, or to other clients violating
the protocol. Maybe BIND 9 tries to leave the connection open no matter
what, but that's an implementation decision, not a protocol requirement.
Please stop trying to force everybody else to imitate what BIND 9 does.
(Also, please stop pretending that ``recommended'' means ``required.'')

---

From: Greg Hudson <[email-masked]>
Date: 29 Nov 2002 14:02:21 -0500

> was rejected will have to ask the server administrator.

If you receive a REFUSED message from the server, there is pretty much
only one explanation: the server doesn't have you configured as an
authorized secondary.

If the connection is closed, there are several explanations: the server
is djbdns and doesn't have you configured as an authorized secondary,
the server process crashed and the kernel closed the connection, the
server is running through a misconfigured inetd or tcpserver.

I don't think a reasonable implementor can construe a TCP FIN as an
error message.

> the first place, let alone demand an answer, let alone demand an

You say this a lot, but you're only considering one possible case: the
requestor is a twit with no legitimate relationship to the primary.  A
more interesting case is when the primary or secondary is accidentally
misconfigured.

Contrary to what you've said before, making it easier to detect common
misconfigurations is an important aspect of interoperability.

---

From: [email-masked]
Date: Sat, 30 Nov 2002 08:55:20 +1100

> this list is generally _not_ the same as the NS list published in DNS.)

	You didn't answer my question.  In this case the ``clueless twit''
	is the administator of the PRIMARY.  I repeat.  "Does your server
	meet RFC 1034 and return REFUSED under these conditions?"
 
> was rejected will have to ask the server administrator.

	They carry a lot more information when you are trying to
	diagnose a problem for someone else.  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.

	Now having that extra infomation really helps them help their
	customer fix their server.
 
> the first place, let alone demand an answer, let alone demand an

	An authorized user does.  The ISP above is authorized to transfer
	the zone.
 
> (Also, please stop pretending that ``recommended'' means ``required.'')

	Asking for a AXFR is not violating the protocol.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 20:44:39 -0000

> I don't think a reasonable implementor can construe a TCP FIN as an

By exactly the same silly argument, SERVFAIL isn't an error message.
Maybe the server program ran out of memory; maybe the disk died; maybe
the system administrator removed a crucial configuration file; maybe the
operating system ran out of file descriptors; etc.

> misconfigurations is an important aspect of interoperability.

By that argument, anybody using AXFR is violating ``interoperability,''
because my recommended use of rsync-over-ssh does a vastly better job of
detecting and reporting common misconfigurations.

---

From: Greg Hudson <[email-masked]>
Date: 29 Nov 2002 21:27:48 -0500

> operating system ran out of file descriptors; etc.

Those were two unrelated arguments.  The paragraph was not intended to
support the second, merely to argue that REFUSED is much clearer than
FIN.

The reason why I don't think a FIN can reasonably be construed as an
error message is: at the TCP level, it's not an error, and at the DNS
level, it's not a message.  An unexpected FIN is rather analagous to a
Unix seg fault; it's an indication that something went wrong, but it's
not an error message.

> detecting and reporting common misconfigurations.

Sure, the interoperability of AXFR, and DNS in general,suffers from poor
error reporting.  So?  Your original argument was that mandating an
error message for a refused AXFR was not necessary for interoperability
at all.  If that were true, then virtually all IETF protocols would be
violating RFC 2119 by mandating separate error codes for separate
failure conditions.

(Of course, even if rsync-over-ssh of zone files is more interopable in
the area of error reporting, it isn't very interoperable in general; it
won't work between BIND and djbdns servers, for instance.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 03:30:01 -0000

Greg Hudson writes:
> at the DNS level, it's not a message

Irrelevant. The word ``message'' doesn't appear in the text we're
discussing. Anyway, the server hasn't authorized you to ask for AXFR in
the first place, so you have no right to demand a response. Go away.

> Your original argument was that mandating an error message for a
> refused AXFR was not necessary for interoperability at all.  If that
> were true, then virtually all IETF protocols would be violating RFC
> 2119 by mandating separate error codes for separate failure conditions.

You are massively confused. There is a huge difference between saying
``you must _not_ send this packet if you are _not_ in this situation''
and saying ``you must send this packet if you are in this situation.''

Trivial example: A 5yz response to SMTP VRFY means that the server won't
accept mail for that address. Facts:

   (1) It is crucial for interoperability that servers _not_ say 5yz if
       they are _not_ in this situation. Otherwise some clients will
       fail to deliver mail to that address.

   (2) There is absolutely no requirement for servers to say 5yz if they
       _are_ in this situation; and, in fact, most servers instead say
       252, deliberately hiding information from the client. This has no
       effect on interoperability.

Do you understand the difference between #1 and #2? Do you understand
why #1 is an interoperability issue and #2 isn't?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 18:48:03 -0000

[email-masked] writes:
> "Does your server meet RFC 1034 and return REFUSED under these conditions?"

Have you stopped beating your wife, Mark?

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.

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

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.

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.