Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Chris On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote: Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
Chris wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1 as my
DNS.
Are you seeing problems with the actual lookups failing, or just upset
about the log noise?
I get a fair volume of similar failures in my own log on my personal
server (4 live accounts, ~500 messages daily, most spam; log since
weekly rotation on Sunday):
[root@hex ]# grep 'connection refused' /var/log/messages|grep sorbs|awk
'{ print $10; }'|sort|uniq -c
2 113.52.8.150#53
79 174.36.198.233#53
74 174.36.235.174#53
40 67.228.187.34#53
yet the actual lookups don't fail, they fall over to another upstream
server.
If it's really that big a problem, you can suppress all such log
messages in the BIND config. Depending on which syslog daemon you're
using, you may be able to suppress only the SORBS failures from reaching
the log file. I'm not sure, but you may even be able to tell BIND to
either not log failures only for SORBS, or never attempt lookups off of
the failing servers in the first place.
-kgd
Re: Turning off queries to SORBS
From: Chris cpoll...@embarqmail.com Sent: Wednesday, May 13, 2015 8:50 AM To: Jeremy McSpadden Cc: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Dig +trace doesn't work quite like that. It will show you exactly what a recursive DNS server would do on a client's behalf when doing a full recursive query to the Internet -- not forwarding to another DNS caching server. It's very helpful to troubleshoot DNS servers giving bad/stale info but it's not able to help you see your DNS query flow. You just have to look at your /etc/resolv.conf to see where it's pointed and start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't doing full recursive lookups on it's own, then you need to find one or stand up your own private DNS server so you know what it's doing for sure. If you have a high volume of mail (more than a few hundred to a thousand mailboxes as a rough number), I would recommend setting up your own DNS recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then also setup the same thing on each SA mail server but forward to your new private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1. SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not forwarding) - Internet Chris On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote: Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On 5/13/2015 10:08 AM, David Jones wrote: From: Chris cpoll...@embarqmail.com Sent: Wednesday, May 13, 2015 8:50 AM To: Jeremy McSpadden Cc: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Dig +trace doesn't work quite like that. It will show you exactly what a recursive DNS server would do on a client's behalf when doing a full recursive query to the Internet -- not forwarding to another DNS caching server. It's very helpful to troubleshoot DNS servers giving bad/stale info but it's not able to help you see your DNS query flow. You just have to look at your /etc/resolv.conf to see where it's pointed and start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't doing full recursive lookups on it's own, then you need to find one or stand up your own private DNS server so you know what it's doing for sure. If you have a high volume of mail (more than a few hundred to a thousand mailboxes as a rough number), I would recommend setting up your own DNS recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then also setup the same thing on each SA mail server but forward to your new private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1. SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not forwarding) - Internet To make sure you are not forwarding queries to your ISP, check you named.conf file for any forwarders lines. If you have any, remove them so your server will do the lookups itself rather than forwarding them elsewhere. -- Bowie
Re: Turning off queries to SORBS
From: Reindl Harald h.rei...@thelounge.net Sent: Wednesday, May 13, 2015 12:35 PM To: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS Am 13.05.2015 um 19:26 schrieb David Jones: Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away if you would follow that thread you would know that the named configuration in the meantime *is* a caching nameserver doing recursion I did follow the thread but my point is that you should be able to insulate yourself from all of the bad zone delegations and misconfigured DNS servers out there that would give the connection refused response if you setup your own servers in the proper way. Maybe simply changing from a BIND caching server on localhost to dnsmasq (disable the DHCP server), unbound, or pdns-recursor might at least clear up the noise in /var/log/messages. The more I use pdns-recursor and other DNS servers, the less I like BIND.
Re: Turning off queries to SORBS
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//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//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
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
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.
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?
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
14:46:02 up 2 days, 8:55, 3 users, load average: 0.06, 0.21, 0.22
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
May 13 13:41:52 localhost spamd[7746]: spamd: connection from ip6-localhost
[::1]:32843 to port 783, fd 6
May 13 13:41:52 localhost spamd[7746]: spamd: setuid to chris succeeded
May 13 13:41:52 localhost spamd[7746]: spamd: processing message
d6.e0.17575.18a93...@mx02.agate.dfw.synacor.com for chris:1000
May 13 13:41:52 localhost clamd[1975]: Accepted connection from 127.0.0.1 on
port 1764, fd 13
May 13 13:41:52 localhost named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
May 13 13:42:02 localhost spamd[7746]: spamd: identified spam (25.8/5.0) for
chris:1000 in 9.7 seconds, 21097 bytes.
May 13 13:42:02 localhost spamd[7746]: spamd: result: Y 25 -
Re: Turning off queries to SORBS
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//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//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
Re: Turning off queries to SORBS
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//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//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
Re: Turning off queries to SORBS
Chris wrote:
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
I'm mildly allergic to resolvconf as it seems to Do The Wrong Thing any
time I've let it have its way. Otherwise your DNS cache appears to be
set up correctly.
The search line is a red herring since it's only used, as David Jones
pointed out, on lookups with a tool like host or dig where you've just
specified a host part.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
*nod* I continue to use it on my own server and as a LAN cache because
I'm familiar with it and its minor warts don't cause issue. (And one
arguable misfeature makes certain parts of managing my own LAN DNS a
little simpler.) About all switching would do is give you minor
headaches learning the new configuration, and probably fresh new
confusing log entries.
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.
From your logs, $10 (the tenth blob of non-whitespace) is the lookup
that was attempted. $11 is the remote server your cache tried first and
got refused by.
That looks like essentially the same list as I found, so it looks like
SORBS has a number of bad servers. I checked the list of nameservers
returned by host -t ns dnsbl.sorbs.net, and I find it curious that
only the first one seems to actually be in that list, but given the
scale they're operating on I can imagine several reasons an apparently
uninvolved IP would be responding for their DNSBL subzone.
There's nothing on your end to do other than fiddle with logging to hide
the noise; so long as what you're looking up in DNS can be found on
another server, your client lookups (either by hand with host, dig,
etc or by eg SpamAssassin) will succeed.
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]
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001
This is an advisory rule, mainly used in meta rules.
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
Your BIND cache tried to look up 50.79.197.70.dnsbl.sorbs.net from
174.36.235.174, but was refused, so it tried another nameserver and got
a response (I get 127.0.0.10 as of writing).
It's not so great that one or more of their nameservers is refusing
queries, but their DNSBL data is served from 13 or more logical servers
as listed by host -t ns dnsbl.sorbs.net, and it's likely there's more
than one physical machine for each of those NS listings.
It's only a problem when a zone only *has* one listed nameserver, or
*all* of the nameservers refuse queries. In that case you can't get an
answer, but otherwise your cache (of any flavour) should walk the list
of nameservers until it gets a response of some kind.
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 problem is with a couple of SORBS nameservers, your cache is just
reporting the problem before retrying the query with another one from
the list. SpamAssassin (or any other client doing a DNS lookup) doesn't
know and doesn't care.
What you're seeing logged by BIND is a transient failure that only slows
down lookups in dnsbl.sorbs.net.
-kgd
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 10:12 -0400, Kris Deugau wrote:
Chris wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1 as my
DNS.
Are you seeing problems with the actual lookups failing, or just upset
about the log noise?
I get a fair volume of similar failures in my own log on my personal
server (4 live accounts, ~500 messages daily, most spam; log since
weekly rotation on Sunday):
[root@hex ]# grep 'connection refused' /var/log/messages|grep sorbs|awk
'{ print $10; }'|sort|uniq -c
2 113.52.8.150#53
79 174.36.198.233#53
74 174.36.235.174#53
40 67.228.187.34#53
yet the actual lookups don't fail, they fall over to another upstream
server.
If it's really that big a problem, you can suppress all such log
messages in the BIND config. Depending on which syslog daemon you're
using, you may be able to suppress only the SORBS failures from reaching
the log file. I'm not sure, but you may even be able to tell BIND to
either not log failures only for SORBS, or never attempt lookups off of
the failing servers in the first place.
-kgd
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//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Here's yesterdays:
chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog.1|
grep sorbs|awk '{ print $10; }'|sort|uniq -c
1 '112.89.189.91.dnsbl.sorbs.net/A/IN':
2 '11.67.255.128.dnsbl.sorbs.net/A/IN':
1 '119.123.171.166.dnsbl.sorbs.net/A/IN':
2 '121.34.211.207.dnsbl.sorbs.net/A/IN':
1 '136.207.152.107.dnsbl.sorbs.net/A/IN':
2 '15.6.255.128.dnsbl.sorbs.net/A/IN':
1 '173.190.42.208.dnsbl.sorbs.net/A/IN':
1 '178.18.143.94.dnsbl.sorbs.net/A/IN':
1 '18.167.87.216.dnsbl.sorbs.net/A/IN':
1 '19.94.189.91.dnsbl.sorbs.net/A/IN':
1 '202.135.201.205.dnsbl.sorbs.net/A/IN':
3 '212.163.111.63.dnsbl.sorbs.net/A/IN':
1 '23.164.11.209.dnsbl.sorbs.net/A/IN':
1 '236.47.41.192.dnsbl.sorbs.net/A/IN':
1 '243.86.197.70.dnsbl.sorbs.net/A/IN':
1 '36.58.176.166.dnsbl.sorbs.net/A/IN':
1 '48.200.56.41.dnsbl.sorbs.net/A/IN':
2 '54.139.130.12.dnsbl.sorbs.net/A/IN':
1 '57.103.45.66.dnsbl.sorbs.net/A/IN':
1 '73.31.231.89.dnsbl.sorbs.net/A/IN':
1 '79.242.62.166.dnsbl.sorbs.net/A/IN':
1 '8.167.87.216.dnsbl.sorbs.net/A/IN':
1 '96.207.152.107.dnsbl.sorbs.net/A/IN':
2 'ns0.sorbs.net//IN':
2 'ns0.sorbs.net/A/IN':
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.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
09:46:29 up 2 days, 3:55, 2 users, load average: 0.04, 0.08, 0.11
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 14:08 +, David Jones wrote:
From: Chris cpoll...@embarqmail.com
Sent: Wednesday, May 13, 2015 8:50 AM
To: Jeremy McSpadden
Cc: users@spamassassin.apache.org
Subject: Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote:
dig +trace and see if your ISP is intercepting queries.
--
Jeremy McSpadden | Flux Labs
Local - 850-250-5590x501 | Mobile - 850-890-2543
Fax - 850-254-2955 | Toll Free - 877-699-FLUX
Web - http://www.fluxlabs.net
Jeremy, I'm replying to you again and Ccing the list which I forgot to
do last night. Below are the results of the above command. I don't see
anywhere my ISP is involved. I've put the output on pastebin so it
doesn't get mangled here on the list dig +trace
54.139.130.12.dnsbl.sorbs.net
http://pastebin.com/up0A2xD1
Dig +trace doesn't work quite like that. It will show you exactly what a
recursive DNS server would do on a client's behalf when doing a full
recursive query to the Internet -- not forwarding to another DNS caching
server. It's very helpful to troubleshoot DNS servers giving bad/stale info
but it's not able to help you see your DNS query flow.
You just have to look at your /etc/resolv.conf to see where it's pointed and
start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't
doing full recursive lookups on it's own, then you need to find one or stand
up your own private DNS server so you know what it's doing for sure.
If you have a high volume of mail (more than a few hundred to a thousand
mailboxes as a rough number), I would recommend setting up your own DNS
recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then
also setup the same thing on each SA mail server but forward to your new
private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1.
SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not
forwarding) - Internet
Chris
On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing
this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1
as my
DNS
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
David, here is my /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 127.0.0.1
search PK5001Z
I only get 100 emails a day, most are directed to the appropriate boxes
by procmail even before they get routed through SA. The rest, maybe 30
or so are either going to be marked as ham or spam by SA.
My /etc/bind/named.conf.options
acl goodclients {
127.0.0.1;
localhost;
localnets;
};
options {
directory /var/cache/bind;
recursion yes;
allow-query { goodclients; };
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
My /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
dns-nameservers 127.0.0.1
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
11:10:30 up 2 days, 5:19, 1 user, load average: 0.08, 0.12, 0.13
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 18:59 -0400, Kris Deugau wrote:
Chris wrote:
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
I'm mildly allergic to resolvconf as it seems to Do The Wrong Thing any
time I've let it have its way. Otherwise your DNS cache appears to be
set up correctly.
The search line is a red herring since it's only used, as David Jones
pointed out, on lookups with a tool like host or dig where you've just
specified a host part.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
*nod* I continue to use it on my own server and as a LAN cache because
I'm familiar with it and its minor warts don't cause issue. (And one
arguable misfeature makes certain parts of managing my own LAN DNS a
little simpler.) About all switching would do is give you minor
headaches learning the new configuration, and probably fresh new
confusing log entries.
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.
From your logs, $10 (the tenth blob of non-whitespace) is the lookup
that was attempted. $11 is the remote server your cache tried first and
got refused by.
That looks like essentially the same list as I found, so it looks like
SORBS has a number of bad servers. I checked the list of nameservers
returned by host -t ns dnsbl.sorbs.net, and I find it curious that
only the first one seems to actually be in that list, but given the
scale they're operating on I can imagine several reasons an apparently
uninvolved IP would be responding for their DNSBL subzone.
There's nothing on your end to do other than fiddle with logging to hide
the noise; so long as what you're looking up in DNS can be found on
another server, your client lookups (either by hand with host, dig,
etc or by eg SpamAssassin) will succeed.
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]
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001
This is an advisory rule, mainly used in meta rules.
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
Your BIND cache tried to look up 50.79.197.70.dnsbl.sorbs.net from
174.36.235.174, but was refused, so it tried another nameserver and got
a response (I get 127.0.0.10 as of writing).
It's not so great that one or more of their nameservers is refusing
queries, but their DNSBL data is served from 13 or more logical servers
as listed by host -t ns dnsbl.sorbs.net, and it's likely there's more
than one physical machine for each of those NS listings.
It's only a problem when a zone only *has* one listed nameserver, or
*all* of the nameservers refuse queries. In that case you can't get an
answer, but otherwise your cache (of any flavour) should walk the list
of nameservers until it gets a response of some kind.
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 problem is with a couple of SORBS nameservers, your cache is just
reporting the problem before retrying the query with another one from
the list. SpamAssassin (or any other client doing a DNS lookup) doesn't
know and doesn't care.
What you're seeing logged by BIND is a transient failure that only slows
down lookups in dnsbl.sorbs.net.
-kgd
I understand now Kris, I guess I've been going on about nothing
basically as like you said if the reply from one server fails it tries
another and so on. I don't mind the logging to syslog and I guess I
should have realized awhile back that not every query in every message
fails but it just didn't hit me that way. I guess this happens when you
get old, little things tend to bother you.
Thanks again
Chris
--
Chris
KeyID
Re: Turning off queries to SORBS
Am 14.05.2015 um 00:59 schrieb Kris Deugau: As far as running something other than Bind, I'd run it for many years on my old Mandriva box before it crashed. Once I got it up and running (with some help from the Bind users list) I never had one single problem. *nod* I continue to use it on my own server and as a LAN cache because I'm familiar with it and its minor warts don't cause issue. (And one arguable misfeature makes certain parts of managing my own LAN DNS a little simpler.) About all switching would do is give you minor headaches learning the new configuration, and probably fresh new confusing log entries well, we operate some hundret doomains using BIND as nameservers, but that don't make it the best caching-only resolver while unbound's cache-min-ttl helps to reduce the outgoing dns queries to spamhaus by ignore the very low TTL and the config is just simple, evem a tuned one like below server: verbosity: 1 statistics-interval: 86400 statistics-cumulative: no extended-statistics: no num-threads: 1 outgoing-range: 1024 num-queries-per-thread: 512 msg-cache-slabs: 8 rrset-cache-slabs: 8 infra-cache-slabs: 8 key-cache-slabs: 8 so-rcvbuf: 4m so-sndbuf: 4m minimal-responses: yes msg-cache-size: 96m neg-cache-size: 96m rrset-cache-size: 192m cache-min-ttl: 600 cache-max-ttl: 10800 interface: 127.0.0.1 access-control: 127.0.0.0/8 allow interface-automatic: no port: 53 do-ip4: yes do-ip6: no do-udp: yes max-udp-size: 1024 edns-buffer-size: 1024 do-tcp: yes do-daemonize: yes username: unbound use-syslog: yes log-time-ascii: yes hide-identity: yes hide-version: yes harden-glue: yes harden-dnssec-stripped: no harden-referral-path: no use-caps-for-id: no unwanted-reply-threshold: 1000 do-not-query-localhost: no prefetch: yes prefetch-key: yes signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
Am 13.05.2015 um 18:53 schrieb Reindl Harald: Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted and BTW consider using unbound instead of bind for a caching-only server finally if just some random queries are failing don't bother, the RBLs are a cluster of servers and it happens multiple times each week that barracuda auth servers saying b.barracudacentral.org NXDOMAIN because errors there if you would make a drama for each failing DNS query on a heavy used network you would have a lot to cry - as long as you are not using a forwarder there is not much reason to worry, except your IP itself is on a sorbs blacklist and hence refused - maybe your MX is listed as DUL which is no problem if it is only incoming mail and not intended for sending but a valid reason to reject rbl queries by the policy of the rbl owner signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
From: Reindl Harald h.rei...@thelounge.net Sent: Wednesday, May 13, 2015 11:53 AM To: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted That's not how the search is used in the resolv.conf. It's used when the query contains no dots like a short name. If someone queried for test with that resolv.conf, it would try test.PK5001Z which isn't a valid zone. That doesn't mean a query of example.com would become example.com.PK5001Z like you said above. You are correct about it being a broken query and it should be removed but that isn't causing connection refused errors. You should be pointing to a reliable DNS resolver, like 127.0.0.1 in this case. Then it should either be doing direct lookups or forwarding to a known reliable DNS resolver that is not forwarding to an ISP DNS server like 8.8.8.8. Unbound is a good suggestion. Even dnsmasq would be easy to setup (just disable the DHCP server). Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away.
Re: Turning off queries to SORBS
Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
Am 13.05.2015 um 19:26 schrieb David Jones: Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away if you would follow that thread you would know that the named configuration in the meantime *is* a caching nameserver doing recursion signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
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//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//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
