Bind 8.2.2 P5 hanging up...

Jim Reid jim at rfc1035.com
Fri Feb 4 23:01:31 UTC 2000


>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Kevin> Just because "Cleaned cache" is the last messages you see
    Kevin> in the logs before the failure doesn't necessarily mean
    Kevin> that it's related to the lock-up problem. Turn on debugging
    Kevin> and that will give you a better idea of what it was doing
    Kevin> prior to the failure.

Indeed. However, I think we've lost the plot here. There was a small
but very important snippet of information at the bottom of the
original posting:

    >> Feb 3 15:48:08 (none) named[43]: Cleaned cache of 41 RRsets.
    >> Feb 3 16:30:18 (none) named[43]: ns_req: sendto([172.23.9.2].137): Connection refused

I certainly missed this first time around.

The "connection refused" report is interesting. It means that a
sendto() system call in ns_req failed with this error code. That
probably means that something in the network rejected the query and
returned an ICMP packet with the error code of ICMP_UNREACH_PORT. This
usually means that there's nothing at the destination host that is
listening for data on the destination port number. [You might also get
it from a firewall or router that is blocking undesirable traffic I
suppose.]

Now the detail in the log message indicates that the name server got
this error when it sent an answer to port 137 of IP address
172.23.9.2. ie Something at 172.23.9.2 sent a query with the source
port set to 137, but by the time the name server sent a reply back
there was nothing using that port number. FWIW port 137 is used for
SMB Name Service, which is some NETBIOS thing that I for one know
nothing about and care even less.

So there probably isn't a problem with the name server at all. The
problem lies with whatever used port 137 on 172.23.9.2. A "lost" query
or reply like this will not crash the name server. UDP is an
unreliable transport medium so the name server should expect lost
packets now and again.

If the name server is dying, it'll be unrelated to the cache cleaning
or the vanishing NETBIOS thing at 172.23.9.2.



More information about the bind-users mailing list