On 13 May 2015, at 16:58, Chris wrote:
On Wed, 2015-05-13 at 13:49 -0400, Kris Deugau wrote:
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.
After a fashion that seems so, if you consider fast flux DNS a form of
clustering (I say it is, for nameservers.)
The SOA and 13 in-zone NS records for dnsbl.sorbs.net both have 1-day
TTL's, while the A records for the rbldns$x.sorbs.net names to which the
NS records point have 10-minute TTL's and the IPs those names resolves
to do change, although not every 10 minutes. The sorbs.net serial is
2015050602, implying that the NS records may have been stable for a week
but that there were 2 or three different rounds of changes on May 6.
Currently, 11 of the 13 NS's for the dnsbl zone are responding to me,
sending back 7 different zone serial numbers between them, using epoch
timestamps spread across 1:02:32. That's not unreasonable considering
that the refresh time is 2 hours. There are 2 pairs of serial numbers ~2
minutes apart, so I would guess that's the minimum update frequency. The
other 2 (rbldns0 and rbldns1) aren't responding at all. Interestingly,
the upstream glue NS records (from the sorbs.net authority) pointing at
the rbldns$x names have 10-minute TTLs,
In effect, that means SORBS can swap IP's for their nameservers in and
out and get many more than 13 IP's being hit by different portions of
the net because their nameservers are handing out variant versions of
the zone and clients are looking for new IPs for the nameservers 144
times per day.
[...]
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
No, it tells you that those specific 4 nameserver addresses didn't
respond to queries. Only the first is currently found in a the
collection of authoritative nameservers for dnsbl.sorbs.net, but all of
them have symmetric PTR/A records, implying that they aren't some sort
of poisoning artifact. Also, the last 3 are in small blocks allocated by
SoftLayer to GFI Software, the former owner of SORBS. Finally, the last
2 are also supposed to be authoritative for sorbs.net, and it is
possible for the various TTLs' expiration to leave one in a position of
asking those machines instead of the proper authorities.
So yes: SORBS has some sort of DNS problem, but it isn't fatal.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf and
commented out the 'search' line:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.79.50 listed in dnsbl.sorbs.net]
The output as shown in my syslog is attached which shows
named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Am I screwed up in the head here and it's working as shown in the
markup
above or is the queries to SORBS not working and I need to fix
something?
The queries to SORBS are *eventually* working, because the normal
behavior for BIND is to retry with another server when one doesn't
answer. BIND really wants to tell you about any little problem you'll
listen too, even if it's transient, so you see these events in logs if
you log deeply enough.
