You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chris <cp...@embarqmail.com> on 2015/05/13 03:48:53 UTC
Turning off queries to SORBS
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
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
20:47:11 up 1 day, 14:56, 1 user, load average: 0.66, 0.43, 0.33
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
Posted by Chris <cp...@embarqmail.com>.
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 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
19:32:07 up 1:23, 1 user, load average: 0.12, 0.18, 0.19
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
Posted by Reindl Harald <h....@thelounge.net>.
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: 10000000
do-not-query-localhost: no
prefetch: yes
prefetch-key: yes
Re: Turning off queries to SORBS
Posted by Kris Deugau <kd...@vianet.ca>.
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
Posted by Reindl Harald <h....@thelounge.net>.
Am 20.04.2016 um 14:30 schrieb Michelle Sullivan:
>> $ /opt/local/bin/whois 174.36.198.233
>>
>> [... ARIN record elided ...]
>>
>> Found a referral to rwhois.softlayer.com:4321.
>>
>> %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
>> Solutions, Inc. V-1.5.9.6)
>> network:Class-Name:network
>> network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
>> network:Auth-Area:174.36.192.0/18
>> network:Network-Name:SOFTLAYER-174.36.192.0
>> network:IP-Network:174.36.198.232/30
>> network:IP-Network-Block:174.36.198.232-174.36.198.235
>> network:Organization;I:GFI Software
> Hehe... out of date rwhois server... you expect anything else? :P
>
> (GFI were out of the picture 1 Jul 2011...! )
the problem is most likely a /opt/local/bin/whois from the last century
[harry@rh:~]$ whois --version
Version 5.2.12.
[harry@rh:~]$ ls /usr/bin/whois.md
-rwxr-xr-x 1 root root 136K 2016-03-29 15:54 /usr/bin/whois.md
[harry@rh:~]$ /usr/bin/whois 174.36.198.233
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
#
https://whois.arin.net/rest/nets;q=174.36.198.233?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 174.36.0.0 - 174.37.255.255
CIDR: 174.36.0.0/15
NetName: SOFTLAYER-4-7
NetHandle: NET-174-36-0-0-1
Parent: NET174 (NET-174-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS36351
Organization: SoftLayer Technologies Inc. (SOFTL)
RegDate: 2008-09-12
Updated: 2013-07-12
Ref: https://whois.arin.net/rest/net/NET-174-36-0-0-1
OrgName: SoftLayer Technologies Inc.
OrgId: SOFTL
Address: 4849 Alpha Rd.
City: Dallas
StateProv: TX
PostalCode: 75244
Country: US
RegDate: 2005-10-26
Updated: 2013-02-20
Ref: https://whois.arin.net/rest/org/SOFTL
ReferralServer: rwhois://rwhois.softlayer.com:4321
OrgTechHandle: IPADM258-ARIN
OrgTechName: IP Admin
OrgTechPhone: +1-214-442-0601
OrgTechEmail: ipadmin@softlayer.com
OrgTechRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
OrgAbuseHandle: ABUSE1025-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-214-442-0601
OrgAbuseEmail: abuse@softlayer.com
OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE1025-ARIN
RAbuseHandle: ABUSE1025-ARIN
RAbuseName: Abuse
RAbusePhone: +1-214-442-0601
RAbuseEmail: abuse@softlayer.com
RAbuseRef: https://whois.arin.net/rest/poc/ABUSE1025-ARIN
RTechHandle: IPADM258-ARIN
RTechName: IP Admin
RTechPhone: +1-214-442-0601
RTechEmail: ipadmin@softlayer.com
RTechRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
RNOCHandle: IPADM258-ARIN
RNOCName: IP Admin
RNOCPhone: +1-214-442-0601
RNOCEmail: ipadmin@softlayer.com
RNOCRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
Verweis auf rwhois.softlayer.com:4321 gefunden.
%rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
Solutions, Inc. V-1.5.9.6)
network:Auth-Area:174.36.192.0/18
network:Class-Name:network
network:Street-Address:NA
network:City:NA
network:Postal-Code:27
network:Country-Code:SA
network:Tech-Contact;I:sysadmins@softlayer.com
network:Abuse-Contact;I:abuse@softlayer.com
network:Admin-Contact;I:IPADM258-ARIN
network:Created:2008-06-12 16:43:22
network:Updated:2014-01-20 07:00:50
network:Updated-By:ipadmin@softlayer.com
%ok
Re: Turning off queries to SORBS
Posted by Michelle Sullivan <mi...@sorbs.net>.
Bill Cole wrote:
> On 28 Jan 2016, at 8:54, Michelle Sullivan wrote:
>
> [...]
>
>>> 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.
>> Where do you see GFI? Nothing should show GFI (all the SL stuff is
>> owned by Proofpoint)
>
> Tell that to SL, e.g.:
>
> $ /opt/local/bin/whois 174.36.198.233
>
> [... ARIN record elided ...]
>
> Found a referral to rwhois.softlayer.com:4321.
>
> %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
> Solutions, Inc. V-1.5.9.6)
> network:Class-Name:network
> network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
> network:Auth-Area:174.36.192.0/18
> network:Network-Name:SOFTLAYER-174.36.192.0
> network:IP-Network:174.36.198.232/30
> network:IP-Network-Block:174.36.198.232-174.36.198.235
> network:Organization;I:GFI Software
Hehe... out of date rwhois server... you expect anything else? :P
(GFI were out of the picture 1 Jul 2011...! )
--
Michelle Sullivan
http://www.mhix.org/
Re: Turning off queries to SORBS
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 28 Jan 2016, at 8:54, Michelle Sullivan wrote:
[...]
>> 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.
> Where do you see GFI? Nothing should show GFI (all the SL stuff is
> owned by Proofpoint)
Tell that to SL, e.g.:
$ /opt/local/bin/whois 174.36.198.233
[... ARIN record elided ...]
Found a referral to rwhois.softlayer.com:4321.
%rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
Solutions, Inc. V-1.5.9.6)
network:Class-Name:network
network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
network:Auth-Area:174.36.192.0/18
network:Network-Name:SOFTLAYER-174.36.192.0
network:IP-Network:174.36.198.232/30
network:IP-Network-Block:174.36.198.232-174.36.198.235
network:Organization;I:GFI Software
network:Street-Address:15300 Weston Parkway, Suite 104
network:City:Cary
network:State:NC
network:Postal-Code:27513
network:Country-Code:US
network:Tech-Contact;I:sysadmins@softlayer.com
network:Abuse-Contact;I:abuse@gfi.com
network:Admin-Contact;I:IPADM258-ARIN
network:Created:2010-02-22 10:26:09
network:Updated:2015-04-18 20:06:14
network:Updated-By:ipadmin@softlayer.com
%ok
Re: Turning off queries to SORBS
Posted by Michelle Sullivan <mi...@sorbs.net>.
Very old thread I know, but have been busy elsewhere...
Bill Cole wrote:
>
> 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.
You pretty much sum it up... However it's not to swap IPs its to allow
us to remove any server that gets DDoSed within a few minutes, similarly
if there is a problem with a particular server... It also allows with
generation of new zone deltas every minute to get all the NS records
cached by the querying servers without resorting to EDNS0 (and therefore
TCP) ... which allow me to scale each server to a minimum of 2500
queries per second all the way up to 40,000 queries per second.
>
> No, it tells you that those specific 4 nameserver addresses didn't
> respond to queries.
4 is a little unusual, but 2 or 3 is not and 1 is certain.. As the DNS
servers reload their zones they stop responding, the servers can reload
their zones every 60 seconds.
> 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.
Where do you see GFI? Nothing should show GFI (all the SL stuff is
owned by Proofpoint)
> 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.
For information:
sorbs.net NS servers will give glue and authority to a sub selection of
the RBL servers (rbldns[1-17].sorbs.net currently possible)
each zone loaded into the rbldns servers has a random selection of 7 NS
records (random at time of generation with any 'Down' servers not in the
possible list)
> So yes: SORBS has some sort of DNS problem, but it isn't fatal.
>
No, it's probably normal operation, however it would appear to be an
issue when compared to a non-RBL zone.
> 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.
Some resolvers will send one query to more than one server at the same
time, they then cache the server which responds the fastest as where to
send all future queries until $timeout.
Some send out 3 queries regardless (assuming there are more than 2
servers). (A way to get this to be almost certain behavior is use a
single NS record pointing at multiple A records.)
Some just send out queries to the same servers as they were told about
them, only moving to the next after a lookup failure.
Some servers seem to rotate (round robin) all the NS records in their
caches and will send queries that way.
Some servers randomise the NS servers they will query every time they
make a query.
... The SORBS delegation and RBL servers have their current
setup/design since 2007 because it seems to be the best compromise when
you get DDoSed, and for minimising duplicate data whilst having the
ability to reconfigure your network without *most* people noticing... ;-)
Regards,
--
Michelle Sullivan
http://www.mhix.org/
Re: Turning off queries to SORBS
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 13 May 2015, at 20:24, Chris wrote:
> 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?
Yes.
Re: Turning off queries to SORBS
Posted by Chris <cp...@embarqmail.com>.
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
Re: Turning off queries to SORBS
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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.
Re: Turning off queries to SORBS
Posted by Chris <cp...@embarqmail.com>.
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.
>
> -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
Re: Turning off queries to SORBS
Posted by Kris Deugau <kd...@vianet.ca>.
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
Re: Turning off queries to SORBS
Posted by Chris <cp...@embarqmail.com>.
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/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.
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/AAAA/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
Posted by Kris Deugau <kd...@vianet.ca>.
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
Posted by Bowie Bailey <Bo...@BUC.com>.
On 5/13/2015 10:08 AM, David Jones wrote:
>> From: Chris <cp...@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 +0000, 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
Posted by David Jones <dj...@ena.com>.
>From: Reindl Harald <h....@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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: Turning off queries to SORBS
Posted by David Jones <dj...@ena.com>.
>From: Reindl Harald <h....@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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: Turning off queries to SORBS
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: Turning off queries to SORBS
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2015-05-13 at 14:08 +0000, David Jones wrote:
> >From: Chris <cp...@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 +0000, 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 <cp...@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
Posted by David Jones <dj...@ena.com>.
>From: Chris <cp...@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 +0000, 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 <cp...@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
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2015-05-13 at 02:05 +0000, 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 <cp...@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
Posted by Jeremy McSpadden <je...@fluxlabs.net>.
dig +trace and see if your ISP is intercepting queries.
--
Jeremy McSpadden | Flux Labs
Local - 850-250-5590x501<tel:850-250-5590;501> | Mobile - 850-890-2543<tel:850-890-2543>
Fax - 850-254-2955<tel:850-254-2955> | Toll Free - 877-699-FLUX<tel:877-699-FLUX>
Web - http://www.fluxlabs.net<http://www.fluxlabs.net/>
On May 12, 2015, at 8:49 PM, Chris <cp...@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':<http://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
--
Chris
KeyID 0xE372A7DA98E6705C
31.11?N 97.89?W (Elev. 1092 ft)
20:47:11 up 1 day, 14:56, 1 user, load average: 0.66, 0.43, 0.33
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015