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. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 17:14:44 up 54 min, 1 user, load average: 0.26, 0.49, 0.52 Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
signature.asc
Description: This is a digitally signed message part
