Re: axfr-clarify supporting unauthorized users

["D. J. Bernstein" <djb@cr.yp.to>]

[ 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
  54830374684695-namedroppers@sublist.cr.yp.to, 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 namedroppers-owner@ops.ietf.org and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

Mark.Andrews@isc.org 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.)

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

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