Re: axfr-clarify supporting unauthorized users

[Mark.Andrews@isc.org]

> [ post by non-subscriber.  with the massive amount of spam, it is easy to mis
> s
>   and therefore delete posts by non-subscribers.  your subscription address i
> s
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo
> u
>   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.)

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

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

	An authorized user does.  The ISP above is authorized to transfer
	the zone.
 
>   [ 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.'')

	Asking for a AXFR is not violating the protocol.

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