Chris wrote:
> Not upset about the 'noise', to my untrained eye it looks to me as if
> the lookups are failing:
>
> chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog|grep
> sorbs|awk '{ print $10; }'|sort|uniq -c
> 1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
> 1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
> 1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
> 1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
> 1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
> 2 'aftershock.sorbs.net/A/IN':
> 2 'cannonball.sorbs.net/A/IN':
> 2 'ns0.sorbs.net/A/IN':
> 1 'ns2.sorbs.net/AAAA/IN':
> 3 'ns2.sorbs.net/A/IN':
> 1 'ns4.sorbs.net/AAAA/IN':
> 3 'ns4.sorbs.net/A/IN':
>
> The above is just from todays syslog starting at 7:40 this morning.
Try print $11 in the awk (this prints the 11th "field" or non-whitespace
chunk); that should show the failing server IP instead of the lookup.
Your log seems to have another non-whitespace blob somewhere earlier in
the line compared to mine, where the remote server IP is the 10th field:
May 13 07:52:57 hex named[3790]: connection refused resolving
'130.102.149.83.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Also try doing the lookups that appear to fail with dig or host, and see
if the actual client lookup succeeds or fails; just because one
nameserver for a zone refused the connection doesn't mean the actual
lookup failed.
I tried the first 5 above plus a couple more from my own log, and all
returned NXDOMAIN - except one lookup took a few seconds to return, so
it probably hit one of those nameservers that's not accepting connections.
> I really don't want to suppress the syslog entries nor do I not want to
> query SORBS, I would just like to figure out why the connection is
> refused.
The particular nameservers refusing connections are either failed or
overloaded. A big DNSBL like SORBS has many nameservers, and it's
likely that each entry from eg "dig dnsbl.sorbs.net ns" is a cluster of
machines.
-kgd
