Re: Turning off queries to SORBS
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=false=false=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: ipad...@softlayer.com OrgTechRef:https://whois.arin.net/rest/poc/IPADM258-ARIN OrgAbuseHandle: ABUSE1025-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-214-442-0601 OrgAbuseEmail: ab...@softlayer.com OrgAbuseRef:https://whois.arin.net/rest/poc/ABUSE1025-ARIN RAbuseHandle: ABUSE1025-ARIN RAbuseName: Abuse RAbusePhone: +1-214-442-0601 RAbuseEmail: ab...@softlayer.com RAbuseRef:https://whois.arin.net/rest/poc/ABUSE1025-ARIN RTechHandle: IPADM258-ARIN RTechName: IP Admin RTechPhone: +1-214-442-0601 RTechEmail: ipad...@softlayer.com RTechRef:https://whois.arin.net/rest/poc/IPADM258-ARIN RNOCHandle: IPADM258-ARIN RNOCName: IP Admin RNOCPhone: +1-214-442-0601 RNOCEmail: ipad...@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:sysadm...@softlayer.com network:Abuse-Contact;I:ab...@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:ipad...@softlayer.com %ok signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
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
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:sysadm...@softlayer.com network:Abuse-Contact;I:ab...@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:ipad...@softlayer.com %ok
Re: Turning off queries to SORBS
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
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
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
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
dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501tel:850-250-5590;501 | Mobile - 850-890-2543tel:850-890-2543 Fax - 850-254-2955tel:850-254-2955 | Toll Free - 877-699-FLUXtel:877-699-FLUX Web - http://www.fluxlabs.nethttp://www.fluxlabs.net/ On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.commailto: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':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