Re: axfr-clarify supporting unauthorized users

[Greg Hudson <ghudson@MIT.EDU>]

On Fri, 2002-11-29 at 15:44, D. J. Bernstein wrote:
> Greg Hudson writes:
> > 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.
> 
> 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.

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.

> > Contrary to what you've said before, making it easier to detect common
> > 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.

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


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