On 09/18/2017 06:03 PM, Chris wrote:
On Mon, 2017-09-18 at 12:32 -0500, David Jones wrote:
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.0
0
4.5
5
43 RCVD_IN_IADB_LISTED 4 4.26 0.0
0
4.5
5
48 RCVD_IN_IADB_DK 4 4.26 0.0
0
4.5
5
51 RCVD_IN_IADB_RDNS 3 3.19 0.0
0
3.4
1
55 RCVD_IN_IADB_SENDERID 3 3.19 0.0
0
3.4
1
81 RCVD_IN_IADB_OPTIN 1 1.06 0.0
0
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.1
0
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.1
0
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.1
0
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
iadb.isipp.com. 172800 IN NS ns
1.ns
.isipp.com.
iadb.isipp.com. 172800 IN NS c.
auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS ns
01.b
ackupdns.com.
iadb.isipp.com. 172800 IN NS ns
2.pr
gmr.com.
iadb.isipp.com. 172800 IN NS ns
2.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.ht
ml
Went there, isipp.com shows all in the green however I see this my
syslog - https://pastebin.com/t11tVGeW
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.
Checking that IP I get the same entries in my syslog and this from the
site - https://pastebin.com/NQpTaAC5
Needless to say I seem to be confusing myself more every time I read a
reply to my original post. After a kernel update I rebooted and see
this:
localhost dnsmasq[2323]: started, version 2.75 cachesize 150
localhost dnsmasq[2323]: compile time options: IPv6 GNU-getopt DBus
i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-
detect inotify
localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
192.168.122.254, lease time 1h
localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively to
interface virbr0
localhost dnsmasq[2323]: reading /etc/resolv.conf
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
localhost dnsmasq[2323]: read
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
localhost dnsmasq-dhcp[2323]: read
/var/lib/libvirt/dnsmasq/default.hostsfile
I'm not really running a mail server in the true sense of the word I
believe. Fetchmail queries my email accounts and pipes the messages
through procmail. Anything that doesn't already have a recipe is run
through SA. I'm just using Bind to speed up the queries that SA makes.
I believe I'm stating that correctly but who knows could be way off.
If I can give any other information I'll be glad to do it. Again, I
have no idea why the queries are going to 168.150.251.35. There hasn't
been another query to isipp since a bit after noon. I'll see what
happens the next time there is one.
Run 'netstat -tunlap | grep ":53 "' and see what is listening on port 53
as your DNS server. You probably need to remove/uninstall dnsmasq.
Here's my output:
# netstat -tunlap | grep ":53 "
tcp 0 0 127.0.0.1:53 0.0.0.0:*
LISTEN 24019/pdns_recursor
udp 0 0 127.0.0.1:53 0.0.0.0:*
24019/pdns_recursor
Once you know you are only running named on port 53, then make sure your
named.conf doesn't have any forwarders defined in the options section.
Now check your logs and see if you are still getting a lot of refused
responses. BIND should be doing full recursive lookups directly to the
authoritative DNS servers just like you saw with the "dig +trace" command.
--
David Jones
