On Wed, 2015-05-13 at 20:19 -0400, Bill Cole wrote:
> 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.
So I guess then that the bottom line is that eventually the queries are
getting through to SORBS but I'll still be seeing some errors and just
don't worry about it. Does that sound about right?
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
19:23:20 up 1:14, 1 user, load average: 0.14, 0.17, 0.18
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
