On 09/18/2017 11:14 AM, Chris wrote:
On Mon, 2017-09-18 at 11:11 -0400, Bill Cole wrote:
On 18 Sep 2017, at 10:57, Chris wrote:
[...]
I am receiving many hits on *_IADB_* rules just fine recently for
emails
from constantcontact.com and others.
I'm receiving rule hits:
TOP HAM RULES FIRED
RANK RULE NAME COUNT %OFMAIL
%OFSPAM %OFHAM
40 RCVD_IN_IADB_SPF 4 4.26 0.00 4.5
5
43 RCVD_IN_IADB_LISTED 4 4.26 0.00 4.5
5
48 RCVD_IN_IADB_DK 4 4.26 0.00 4.5
5
51 RCVD_IN_IADB_RDNS 3 3.19 0.00 3.4
1
55 RCVD_IN_IADB_SENDERID 3 3.19 0.00 3.4
1
81 RCVD_IN_IADB_OPTIN 1 1.06 0.00 1.1
4
Yesterday instead of seeing host unreachable as I posted above I'm
seeing this
Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected RCODE
resolving 'isipp.com/NS/IN': 168.150.251.35#53
Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected RCODE
resolving 'concerto.isipp.com/A/IN': 168.150.251.35#53
Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected RCODE
resolving '10.232.124.38.iadb.isipp.com/A/IN': 168.150.251.35#53
Why are you asking 168.150.251.35 to do DNS resolution for you? It is
not authoritative for isipp.com, so presumably you have a specific
local config causing you to use it. It is explicitly refusing to do
DNS resolution for you.
I honestly have no idea where that came about. I know that on Saturday
I was seeing this:
SERVFAIL unexpected RCODE resolving
'121.244.54.142.iadb.isipp.com/A/IN': 67.227.187.192#53
Then yesterday I started seeing
named[1284]: REFUSED unexpected RCODE resolving 'isipp.com/NS/IN':
168.150.251.35#53
So to be honest I have no idea where it's coming from. Something
appears to be messed up somewhere to be sure. However, I've made
absolutely no changes to anything.
Check your /etc/resolv.conf and make sure that something didn't change
it. Most SA instances should have a local DNS caching server so
/etc/resolv.conf should be pointing to 127.0.0.1 and the local DNS
server should be doing it's own recursive lookups -- not forwarding to
any other DNS server so your queries don't get combined with others and
go over daily usages limits that many RBLs have. This has been covered
extensively on this list if you want to search the archives for
URIBL_BLOCKED.
Run a "dig +trace" from the SA server where the /etc/resolv.conf is
pointed to 127.0.0.1 to troubleshoot and you should get some responses
similar to this:
dig +trace 65.43.116.208.iadb.isipp.com
...
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.0.1
65.43.116.208.iadb.isipp.com. 3600 IN A 127.2.255.3
65.43.116.208.iadb.isipp.com. 3600 IN A 127.2.255.4
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.0.2
65.43.116.208.iadb.isipp.com. 3600 IN A 127.101.202.10
65.43.116.208.iadb.isipp.com. 3600 IN A 127.3.100.10
65.43.116.208.iadb.isipp.com. 3600 IN A 127.2.255.1
65.43.116.208.iadb.isipp.com. 3600 IN A 127.101.201.10
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
If you don't get some 127.xx.xx.xx responses then look at the dig output
to see where things stop. The first "hop" should be from 127.0.0.1 then
start walking down the DNS tree from right to left.
--
David Jones
