WHY?!? Why do I get "Connection refused"??

[Mark.Andrews at nominum.com]

> In article <10470.965238530 at gromit.rfc1035.com>,
> Jim Reid  <jim at rfc1035.com> wrote:
> >>>>>> "Patrick" == Patrick Klos <patrick at klos.com> writes:
> >
> >    Patrick> What cause the following message??  
> >    Patrick> Jul 31 11:14:23 linux named[55]: recvfrom: Connection refused
> >
> >Consult your local documentation for the recvfrom() system call. This
> >should explain why the call fails ECONNREFUSED "Connection refused".
> 
> Thanks, but I was asking more of a named question rather then a simple
> system question.  I know that "Connection refused" means "the host at
> the other side of this socket either can't or won't respond".  I am
> trying to find out under what circumstances does named experience this
> problem?

	The client has closed it's socket and is no longer listening
	when the reply is sent.  This is a normal condition.

> 
> >    Patrick> While I'm at it, what defines a "brain damage" packet?  I
> >    Patrick> am seeing more and more of these in "Malformed responses".
> >
> >This should be obvious. Your name server is being sent mangled
> >answers. In other words, the packets don't conform to the wire format
> >defined in RFC1035. This either means the sending system has a very
> >badly broken name server or else something is corrupting the packets
> >on their way between the sending and receiving name servers.
> 
> Again, I'm not asking for the obvious reply - I know that something is
> wrong with the packet - I'm curious what are the typical causes for
> "brain damaged" packets?  Are there known implementation problems with
> some common DNS implementations?

	"brain damage" indicates that named found a formerr and
	did not set a specific error message.  There is supposed to
	be a specific error message for each case.  "brain damage"
	indicates that the message was forgotton.  Looking at the
	current code I could not see a path where this would occur.

	Just about all implementations from all vendors have some
	case that can cause form errors.

	Mark

> ============================================================================
>     Patrick Klos                           Email: patrick at klos.com
>     Klos Technologies, Inc.                Web:   http://www.klos.com/
> ============================================================================
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com