On 09/18/2017 11:52 AM, Chris wrote:
On Mon, 2017-09-18 at 11:40 -0500, David Jones wrote:
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.
Here's what I see:
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.3.100.10
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.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.2.255.3
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.0.1.255
iadb.isipp.com. 172800 IN NS ns1.ns
.isipp.com.
iadb.isipp.com. 172800 IN NS c.auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS ns01.b
ackupdns.com.
iadb.isipp.com. 172800 IN NS ns2.pr
gmr.com.
iadb.isipp.com. 172800 IN NS ns2.ns
.isipp.com.
iadb.isipp.com. 172800 IN NS a.auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS b.auth
-ns.sonic.net.
;; Received 434 bytes from 216.218.223.67#53(ns2.prgmr.com) in 66 ms
cat 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 was showing a good lookup and you got back the same results as I did.
Next you should have tried the same query to the ones before that were
failing. Here's what I get:
dig +trace 10.232.124.38.iadb.isipp.com
...
(no A records with a 127.xx.xx.xx response)
which means that IP is not listed on this whitelist.
I, like Bill Cole, still don't understand why your server was trying to
do this query to 168.150.251.35 unless you have something overriding the
DNS resolution to forwarders in named.
*** IMPORTANT *** Make sure your named.conf is not forwarding to any
other DNS servers. It should be doing it's own full recursive lookups
just like the "dig +trace" was doing.
I agree with Bill Cole about a dynamic IP but they are primarily a
problem for sending outbound email and not necessarily a problem with
inbound mail filtering. You may experience some oddities here and there
doing certain things so when you do, you have to do a little extra work
to determine what is "normal" and what is caused by not having a static IP.
Use third-party sites to get their view of things to confirm what you
are seeing. Find (Ctrl+F) "isipp.com" on this page to determine if your
DNS server agrees: http://multirbl.valli.org/lookup/38.124.232.10.html
Then you can see http://multirbl.valli.org/lookup/208.116.43.65.html
does list that other IP the same way your "dig +trace
65.43.116.208.iadb.isipp.com" did. Now make sure your named is not
forwarding and you should be good to go.
--
David Jones
