You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by "Kevin A. McGrail" <ke...@mcgrail.com> on 2017/09/16 13:45:08 UTC
Re: bb.barracudacentral.org
Chris & all,
I have opened a bug about this:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7471
I believe scoring it 0 for now will disable the rule but that's just
hiding the issue.
Thanks for bringing it to the list, Chris.
Regards,
KAM
Re: bb.barracudacentral.org
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 9/17/2017 8:35 AM, Benny Pedersen wrote:
> i find this simply with postscreen in postfix
I use and love mimedefang. With it, I'm able to record a lot more data,
track things with Redis, etc. I should have been more clear.
I find that throwing immense resources at our spam filtering is better
to keep FPs low which keeps my users happier.
YMMV.
> it is free, just with very low query limits now, much lower then other
> rbls is :/
>
> so say it should be considered to be removed or default disabled
Agreed. If they don't meet our RBL inclusion policy any longer that
will occur. I have reached out to them and there is a ticket concerning
it and their changed limits in bugzilla.
Regards,
KAM
Re: bb.barracudacentral.org
Posted by Benny Pedersen <me...@junc.eu>.
Kevin A. McGrail skrev den 2017-09-17 01:30:
> I am a bad person to ask because I don't trust most any RBLS to use
> them as a poison pill at the smtp level.
start using more WHITELISTS then :=)
i find this simply with postscreen in postfix
> The bb list was setup specifically for spamassassin and goes against
> the spirit of the free for most policy we use to allow commercial
> providers to be included by default.
it is free, just with very low query limits now, much lower then other
rbls is :/
so say it should be considered to be removed or default disabled
> It's a bit of a free
> advertisement for them but designed with a barrier that many small
> users will never exceed the thresholds.
but its limit to around 100 query's pr day now :(
>> I'm using b.barracuda.org with postfix. Perhaps you could also use
>> bb.barracuda.org there as well? Does it make sense to use it for both
>> SA and postfix?
that was the intention that b. was with fewer false positive reject
listings, where bb. had all listings, and imho asvel that helps to
spread loads on the rbl servers for both, but if it's only serving
around 100 now it's irelational
bb. have same ip listnings as b. so using both does not block more
Re: bb.barracudacentral.org
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
I am a bad person to ask because I don't trust most any RBLS to use them as a poison pill at the smtp level.
The bb list was setup specifically for spamassassin and goes against the spirit of the free for most policy we use to allow commercial providers to be included by default. It's a bit of a free advertisement for them but designed with a barrier that many small users will never exceed the thresholds.
Regards,
KAM
>I'm using b.barracuda.org with postfix. Perhaps you could also use
>bb.barracuda.org there as well? Does it make sense to use it for both
>SA and postfix?
Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
On 09/16/2017 11:52 AM, Alex wrote:
> Hi,
>
> On Sat, Sep 16, 2017 at 9:45 AM, Kevin A. McGrail
> <ke...@mcgrail.com> wrote:
>> Chris & all,
>> I have opened a bug about this:
>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7471
>>
>> I believe scoring it 0 for now will disable the rule but that's just hiding
>> the issue.
>>
>> Thanks for bringing it to the list, Chris.
>
> I'm using b.barracuda.org with postfix. Perhaps you could also use
> bb.barracuda.org there as well? Does it make sense to use it for both
> SA and postfix?
>
> postscreen_dnsbl_threshold = 8
> postscreen_dnsbl_sites =
> mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
> score.senderscore.com=127.0.4.[0..19]*5
> score.senderscore.com=127.0.4.[20..29]*4
> score.senderscore.com=127.0.4.[30..49]*3
> score.senderscore.com=127.0.4.[50..59]*2
> score.senderscore.com=127.0.4.[60..69]*1
> score.senderscore.com=127.0.4.[70..79]*-1
> score.senderscore.com=127.0.4.[80..89]*-2
> score.senderscore.com=127.0.4.[90..100]*-3
> b.barracudacentral.org*7
> mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
> bl.mailspike.net*4
> bl.spamcop.net*4
> bl.spameatingmonkey.net*4
> mykey.zen.dq.spamhaus.net=127.0.0.3*4
> mykey.invaluement.com=127.0.0.2*8
> mykey24.invaluement.com=127.0.0.2*6
> ubl.unsubscore.com=127.0.0.2*1
> list.dnswl.org=127.[0..255].[0..255].0*-2
> list.dnswl.org=127.[0..255].[0..255].1*-3
> list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
> dnsbl.sorbs.net=127.0.0.[10;14]*8
> dnsbl.sorbs.net=127.0.0.5*7
> dnsbl.sorbs.net=127.0.0.7*4
> dnsbl.sorbs.net=127.0.0.6*3
> dnsbl.sorbs.net=127.0.0.[8;9]*2
> dnsbl.sorbs.net=127.0.0.4*1
>
In general you should use RBLs in both the MTA and SA for double layers
of protection. With a local caching DNS server, it shouldn't cause
extra DNS queries to authoritative DNS servers. It's possible that a
whitelist in postscreen could let an email past the MTA so you also want
SA to use it in the overall score. Also, SA should be checking RBLs for
proper outbound filtering.
In this case, the b. and bb. were designed for different purposes so I
would leave things as they are which is how I have my settings.
Here are the number of blocked messages by Postfix postscreen the past
week and b.barracudacentral.org is near the top and doing well with a
similar config as above:
zen.spamhaus.org 1439544
sip.invaluement.com 1427555
b.barracudacentral.org 704359
dnsbl.sorbs.net 147540
dnsbl.inps.de 125382
hostkarma.junkemailfilter.com 6219
sip24.invaluement.com 2178
bl.spamcop.net 1515
uri.invaluement.com 1508
Don't point to invaluement.com unless you are paying (very reasonable
price) for a subscription. I have a local rbldnsd authoritative zone.
--
David Jones
Re: bb.barracudacentral.org
Posted by Alex <my...@gmail.com>.
Hi,
On Sat, Sep 16, 2017 at 9:45 AM, Kevin A. McGrail
<ke...@mcgrail.com> wrote:
> Chris & all,
> I have opened a bug about this:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7471
>
> I believe scoring it 0 for now will disable the rule but that's just hiding
> the issue.
>
> Thanks for bringing it to the list, Chris.
I'm using b.barracuda.org with postfix. Perhaps you could also use
bb.barracuda.org there as well? Does it make sense to use it for both
SA and postfix?
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_sites =
mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
score.senderscore.com=127.0.4.[0..19]*5
score.senderscore.com=127.0.4.[20..29]*4
score.senderscore.com=127.0.4.[30..49]*3
score.senderscore.com=127.0.4.[50..59]*2
score.senderscore.com=127.0.4.[60..69]*1
score.senderscore.com=127.0.4.[70..79]*-1
score.senderscore.com=127.0.4.[80..89]*-2
score.senderscore.com=127.0.4.[90..100]*-3
b.barracudacentral.org*7
mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4
bl.spamcop.net*4
bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
mykey.invaluement.com=127.0.0.2*8
mykey24.invaluement.com=127.0.0.2*6
ubl.unsubscore.com=127.0.0.2*1
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
dnsbl.sorbs.net=127.0.0.[10;14]*8
dnsbl.sorbs.net=127.0.0.5*7
dnsbl.sorbs.net=127.0.0.7*4
dnsbl.sorbs.net=127.0.0.6*3
dnsbl.sorbs.net=127.0.0.[8;9]*2
dnsbl.sorbs.net=127.0.0.4*1
Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Sat, 2017-09-16 at 16:32 +0200, Reindl Harald wrote:
>
> Am 16.09.2017 um 16:27 schrieb Chris:
> >
> > named[1284]: REFUSED unexpected RCODE resolving
> > '165.170.166.108.iadb.isipp.com/A/IN': 168.150.251.35#53
> > named[1284]: host unreachable resolving
> > '165.170.166.108.iadb.isipp.com/A/IN': 67.227.190.38#53
> > named[1284]: SERVFAIL unexpected RCODE resolving
> > '165.170.166.108.iadb.isipp.com/A/IN': 67.227.187.192#53
> works here
>
> >
> > $ grep -ri isipp
> > /var/lib/spamassassin/3.004001/updates_spamassassin_org
> > Binary file
> > /var/lib/spamassassin/3.004001/updates_spamassassin_org/30_text_pt_
> > br.c
> > f matches
> > /var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dnsbl_te
> > sts.
> > cf:header __RCVD_IN_IADB eval:check_rbl('iadb-
> > firsttrusted',
> > 'iadb.isipp.com.')
> > /var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dnsbl_te
> > sts.
> > cf:describe RCVD_IN_IADB_VOUCHED ISIPP IADB lists as vouched-for
> > sender
> >
> > I notice that they're a 'pay for use' service or at least that's
> > what I
> > can see on their webpage.
> this is a WHITELIST and you pay for get listed, pay for use it would
> make no sense at all because in that case it becomes meaningsless
> and
> nobody would pay to get listed
>
Ok, I see now. That makes more sense to pay to get listed, not to use.
My mistake, I misread it.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
09:35:08 up 7 days, 17:03, 1 user, load average: 0.88, 0.83, 0.70
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-33-generic
Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Sat, 2017-09-16 at 09:45 -0400, Kevin A. McGrail wrote:
> Chris & all,
> I have opened a bug about this:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7471
>
> I believe scoring it 0 for now will disable the rule but that's just
> hiding the issue.
>
> Thanks for bringing it to the list, Chris.
>
> Regards,
> KAM
>
The 0 score did disable the list Kevin, thanks for suggesting it and
thanks for filing the bug. I had been focusing on the bb.barracuda
issue and neglected to notice this one also:
named[1284]: REFUSED unexpected RCODE resolving
'165.170.166.108.iadb.isipp.com/A/IN': 168.150.251.35#53
named[1284]: host unreachable resolving
'165.170.166.108.iadb.isipp.com/A/IN': 67.227.190.38#53
named[1284]: SERVFAIL unexpected RCODE resolving
'165.170.166.108.iadb.isipp.com/A/IN': 67.227.187.192#53
This is found
$ grep -ri isipp
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Binary file
/var/lib/spamassassin/3.004001/updates_spamassassin_org/30_text_pt_br.c
f matches
/var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dnsbl_tests.
cf:header __RCVD_IN_IADB eval:check_rbl('iadb-firsttrusted',
'iadb.isipp.com.')
/var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dnsbl_tests.
cf:describe RCVD_IN_IADB_VOUCHED ISIPP IADB lists as vouched-for
sender
I notice that they're a 'pay for use' service or at least that's what I
can see on their webpage.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
09:10:31 up 7 days, 16:38, 1 user, load average: 0.70, 0.41, 0.45
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-33-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by John Hardin <jh...@impsec.org>.
On Mon, 18 Sep 2017, Bill Cole wrote:
> On 18 Sep 2017, at 12:14, Chris wrote:
> [...]
>> On Mon, 2017-09-18 at 11:11 -0400, Bill Cole wrote:
>>> 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.
>
> Do you have a local caching recursive DNS resolver? NOT dnsmasq and not
> anything configured to forward anywhere: A *REAL* recursive caching DNS
> resolver.
When discussing this topic I recommend avoiding the term "caching"
entirely. Mentioning that word distracts from the crucial "NOT FORWARDING"
part, even if you also say "recursive" as well...
We've all seen discussions of this get off-track because of that detail.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If stress is going to kill me, I wish it would hurry up and
get it over with.
-----------------------------------------------------------------------
Tomorrow: Talk Like a Pirate day
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 18 Sep 2017, at 12:14, Chris wrote:
[...]
> On Mon, 2017-09-18 at 11:11 -0400, Bill Cole wrote:
>> 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.
Do you have a local caching recursive DNS resolver? NOT dnsmasq and not anything configured to forward anywhere: A *REAL* recursive caching DNS resolver.
Are you allowing DHCP or some other dynamic network configuration tool control your /etc/resolv.conf?
What's in your /etc/resolv.conf?
If you want to run a working mail server, particularly one that uses DNSBLs of any sort, you need a local (same machine or at worst same physical LAN) caching recursive DNS resolver. /etc/resolv.conf should be static and contain the line "nameserver 127.0.0.1" and probably nothing else.
> 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
Which means that you asked 67.227.187.192 (ns2.ns.isipp.com, which is authoritative for iadb.isipp.com.) for the A record of 121.244.54.142.iadb.isipp.com (a DNSBL query) but that DNS server was broken in some way and couldn't provide any meaningful reliable answer other than "I'm Broken!"
Stuff happens.
> Then yesterday I started seeing
>
> named[1284]: REFUSED unexpected RCODE resolving 'isipp.com/NS/IN':
> 168.150.251.35#53
Which means that you asked 168.150.251.35 (which has 2 names: dcn-colo-251-35.dcn.davis.ca.us and iannet.net) for the NS record for isipp.com. There's no clear reason for you to do that based on the public DNS for isipp.com. It's response to your query was explicitly "GET LOST!"
> 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.
But you've had things changed, right? By which I mean: you have a dynamic IP. That implies DHCP, which also can change your DNS resolver(s). This is a thing you should not allow it to do if you are running a mail server, especially if your dynamic IP might come from random unrelated networks, some of which impose a DNS resolver on you and others which may not. So you COULD end up changing networks and hence IP address but retaining a stale entry in /etc/resolv.conf that points to a machine that will not answer queries from your new IP.
(And yes, the bottom line is: DO NOT EXPECT TO BE ABLE TO RUN A STABLE USEFUL MAIL SERVER WITHOUT A STATIC IP!)
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 21:32 -0700, Ian Zimmerman wrote:
> On 2017-09-19 19:53, David B Funk wrote:
>
> >
> > So now you have -two- dnsmasq kits, one installed by "apt" and
> > managed
> > thru the "systemctl" tools, and another one that somebody put there
> > which is outside the realm of "apt" & "systemctl" (thus they don't
> > know how to manange it).
> >
> > You should really pick one method of installing/managing software
> > and
> > stick with it.
> >
> > This is similar to the mess you get when you mix CPAN with
> > yum/yast/rpm/apt for installing Perl modules.
> Similar but worse, as you can have a safe CPAN + distro mix with
> local::lib.
>
As I've said in a previous post I 'only' install official Ubuntu pkgs
via apt except I have a beta of fetchmail currently in use.
I'm not sure if removing certain snap pkgs I have installed will also
remove dnsmasq or not or if it was automatically installed when 'core'
was installed.
/snap/core/2925/etc/dnsmasq.d
/snap/core/2925/etc/dbus-1/system.d/dnsmasq.conf
/snap/core/2925/etc/dnsmasq.d/ubuntu-fan
/snap/core/2925/run/dnsmasq
/snap/core/2925/usr/sbin/dnsmasq
/snap/core/2925/usr/share/dnsmasq-base
/snap/core/2925/usr/share/dnsmasq-base/trust-anchors.conf
core 16-2.28~rc3 2925 canonical core
dwarf-fortress 0.43.05 2 mterry -
nethack 3.4.2-2 2 ogra -
pubip 0.6 28 thibran -
snappy-debug 0.31.4-snapd2.26.9 70 canonical -
snapweb 0.26-11-dev 307 canonical -
speed-test 1.8.0 16 bartaz -
wallpaperdownloader 2.8 16 egarcia -
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:58:22 up 12:11, 1 user, load average: 0.47, 0.57, 0.71
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Ian Zimmerman <it...@very.loosely.org>.
On 2017-09-19 19:53, David B Funk wrote:
> So now you have -two- dnsmasq kits, one installed by "apt" and managed
> thru the "systemctl" tools, and another one that somebody put there
> which is outside the realm of "apt" & "systemctl" (thus they don't
> know how to manange it).
>
> You should really pick one method of installing/managing software and
> stick with it.
>
> This is similar to the mess you get when you mix CPAN with
> yum/yast/rpm/apt for installing Perl modules.
Similar but worse, as you can have a safe CPAN + distro mix with local::lib.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 15:22 -0700, Ian Zimmerman wrote:
> On 2017-09-20 17:02, Chris wrote:
>
> >
> > So, IIUC it would be a good idea to remove the resolv.conf symlink
> > in
> > /run/resolvconf ?
> Definitely _not_ a good idea while the resolvconf package is
> installed.
>
> What I meant was remove the package first, then clean up.
>
Understand Ian, thanks
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
19:40:09 up 22:52, 1 user, load average: 0.60, 0.58, 0.50
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Ian Zimmerman <it...@very.loosely.org>.
On 2017-09-20 17:02, Chris wrote:
> So, IIUC it would be a good idea to remove the resolv.conf symlink in
> /run/resolvconf ?
Definitely _not_ a good idea while the resolvconf package is installed.
What I meant was remove the package first, then clean up.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 08:01 -0700, Ian Zimmerman wrote:
> On 2017-09-20 11:15, Martin Gregorie wrote:
>
> >
> > I don't know why you'd want to do that since you should be running
> > named instead of dnsmasq.
> >
> > Delete the version you just installed via the apt package manager
> > and
> > do a search and destroy mission to get rid of both the other copy
> > of
> > it and the associated configuration.
> >
> > Running "updatedb; locate dnsmasq" is probably the fastest way of
> > finding it and its associated files. Anything with a similar name
> > in
> > /etc/init.d is probably its launcher script, so that can go too. If
> > you have an /etc/rc.local file, check its contents because its run
> > as
> > part of the sysVinit process. It shouldn't have anything about
> > dnsmasq
> > in it but you never know...
> Another thing to check in this kind of mess (and I think it wasn't
> mentioned yet) is the state of /etc/resolv.conf. In Debian (and so
> in
> Ubuntu, too) packages that provide DNS daemons, whether authoritative
> or
> caching only, attempt to manage that file automatically, if the
> resolvconf (traditionally) or openresolv package is also
> installed. If
> you do something "unexpected" you can end up with /etc/resolv.conf in
> a
> strange state.
>
Hi Ian, my /etc/resolv.conf is linked to /run/resolvconf/resolv.conf.
Both appear to be the same. I don't know why the nameserver line is
there twice.
/run/resolvconf/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
The /etc/resolv.conf is exactly the same.
> To avoid that, on my Debian hosts I usually purge
> resolvconf/openresolv,
> make sure that /etc/resolv.conf is a real file (not a symlink), and
> manually edit it to the correct state. If the host is on DHCP I also
> make sure the ISC DHCP client is in use (not dhcpcd which seems to be
> much less flexible), and change /etc/dhcp/dhclient.conf to not
> request
> (or override) the DNS info provided by DHCP, as that also messes with
> resolv.conf.
>
So, IIUC it would be a good idea to remove the resolv.conf symlink in
/run/resolvconf ?
> Finally (and getting really OT), it helps to keep relevant /etc files
> under version control, so you know when the system helpfully shifts
> the
> ground under you.
>
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:42:52 up 19:55, 1 user, load average: 0.65, 0.59, 0.83
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2017-09-20 at 08:01 -0700, Ian Zimmerman wrote:
> Finally (and getting really OT), it helps to keep relevant /etc files
> under version control, so you know when the system helpfully shifts
> the ground under you.
>
Really good advice.
I keep a copy of all the configuration files I've manually created or
changed. These are held in a normal user in a directory structure that
mimics /etc, which makes it easier to manage and to put my versions
back as and when needed. These copies are under version control and so
are automatically backed up whenever /home is backed up.
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Ian Zimmerman <it...@very.loosely.org>.
On 2017-09-20 11:15, Martin Gregorie wrote:
> I don't know why you'd want to do that since you should be running
> named instead of dnsmasq.
>
> Delete the version you just installed via the apt package manager and
> do a search and destroy mission to get rid of both the other copy of
> it and the associated configuration.
>
> Running "updatedb; locate dnsmasq" is probably the fastest way of
> finding it and its associated files. Anything with a similar name in
> /etc/init.d is probably its launcher script, so that can go too. If
> you have an /etc/rc.local file, check its contents because its run as
> part of the sysVinit process. It shouldn't have anything about dnsmasq
> in it but you never know...
Another thing to check in this kind of mess (and I think it wasn't
mentioned yet) is the state of /etc/resolv.conf. In Debian (and so in
Ubuntu, too) packages that provide DNS daemons, whether authoritative or
caching only, attempt to manage that file automatically, if the
resolvconf (traditionally) or openresolv package is also installed. If
you do something "unexpected" you can end up with /etc/resolv.conf in a
strange state.
To avoid that, on my Debian hosts I usually purge resolvconf/openresolv,
make sure that /etc/resolv.conf is a real file (not a symlink), and
manually edit it to the correct state. If the host is on DHCP I also
make sure the ISC DHCP client is in use (not dhcpcd which seems to be
much less flexible), and change /etc/dhcp/dhclient.conf to not request
(or override) the DNS info provided by DHCP, as that also messes with
resolv.conf.
Finally (and getting really OT), it helps to keep relevant /etc files
under version control, so you know when the system helpfully shifts the
ground under you.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
On 09/19/2017 08:16 AM, Chris wrote:
> On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
>> On 09/18/2017 06:03 PM, Chris wrote:
> [snip]
>>>
>>> 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, here's my output. I ran as sudo to see all inclusive:
>
> sudo netstat -tunlap | grep ":53"
> [sudo] password for chris:
> tcp 0 0
> 192.168.122.1:53 0.0.0.0:* LISTEN 1245/named
>
> tcp 0 0
> 127.0.1.1:53 0.0.0.0:* LISTEN 1316/dnsmas
> q
> tcp 0 0
> 192.168.0.51:53 0.0.0.0:* LISTEN 1245/named
>
> tcp 0 0
> 127.0.0.1:53 0.0.0.0:* LISTEN 1245/named
>
> tcp 0 0
> 192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
>
> tcp 1 1
> 192.168.0.51:33475 198.97.190.53:53 CLOSING -
>
> tcp 0 0
> 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
>
> tcp 0 0
> 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
>
> tcp 1 1
> 192.168.0.51:40633 198.97.190.53:53 CLOSING -
>
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* 2323/dnsmas
> q
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* 1245/named
>
> udp 0 0
> 127.0.1.1:53 0.0.0.0:* 1316/dnsmas
> q
> udp 0 0
> 192.168.0.51:53 0.0.0.0:* 1245/named
>
> udp 0 0
> 127.0.0.1:53 0.0.0.0:* 1245/named
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* 1533/snapwe
> b
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* 1004/avahi-
> daemon:
> udp6 0 0
> :::5353 :::* 1533/snapwe
> b
> udp6 0 0
> :::5353 :::* 1004/avahi-
> daemon:
>
> Chris
>
Wow. I don't think I have ever seen anything listening on 127.0.1.1
before. I would uninstall dnsmasq and make sure named is only listening
on 127.0.0.1 just to make sure that nothing else outside of your box
would try to use it. A mail server should not have any external clients
adding to it's query volume. Granted regular DNS clients probably
aren't going to be doing RBL-style DNS queries but it's best to keep
things separated.
--
David Jones
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 19 Sep 2017, Chris wrote:
> On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
>> On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
>>>
>>>
>>> Thanks Martin, here's what I get, it appears to not be running.
>>>
>>> sudo systemctl stop dnsmasq
>>> [sudo] password for chris:
>>> Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
>>>
>> OK, that makes sense
>>
>>>
>>> sudo systemctl disable dnsmasq
>>> Failed to execute operation: No such file or directory
>>>
>> That's interesting: I've never seen that before:
>>
[snip..]
>> It would be interesting to know what 'systemctl status' shows on your
>> system, though its quite possible it looks similar to what 'systemctl
>> disable' showed. I can only guess that your system is a transitional
>> systemd setup, i.e. systemctl is used for service management but some
>> services (dnsmasq for one) are still running under the old systemV
>> init
>> scripts. Fedora installations used to work that way for some
>> services,
>> but that was a few versions ago (F21 or 22 at the latest).
>>
>>
>> Martin
>>
> Hi Martin, here's what I see:
>
> sudo systemctl status dnsmasq
> [sudo] password for chris:
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
> chris@localhost:~$ sudo systemctl enable dnsmasq
> Failed to execute operation: No such file or directory
> chris@localhost:~$ sudo systemctl status dnsmasq
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
>
> I then installed dnsmasq (apparently it wasn't installed)
>
> Results are here - https://pastebin.com/MRR4NCMp
dnsmasq was already there (see your own previous posts) just not put there via
the "apt" package management system. Thus "apt" didn't know about the rogue
dnsmasq process, and it failed to start the newly installed one.
(as the rogue dnsmasq process was already there, running, and bound to the DNS
socket).
So now you have -two- dnsmasq kits, one installed by "apt" and managed thru the
"systemctl" tools, and another one that somebody put there which is outside the
realm of "apt" & "systemctl" (thus they don't know how to manange it).
You should really pick one method of installing/managing software and stick with
it.
This is similar to the mess you get when you mix CPAN with yum/yast/rpm/apt for
installing Perl modules.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Thu, 2017-09-21 at 11:58 +0100, Martin Gregorie wrote:
> On Wed, 2017-09-20 at 19:39 -0500, Chris wrote:
> >
> > It was installed by default when upgrading from 14.04LTS to
> > 16.04LTS
> >
> Then it may be best to just leave it there.
>
> >
> > I have stopped Network Manager. I've not disabled or removed it yet
> > as I'm watching to see how named does the queries now.
> >
> I didn't suggest removing it - just following the advice from others
> to
> change its configuration so it doesn't try to start dnsmasq or bind:
> leave starting the daemons that should always be running to systemd.
My mistake, I must have read somewhere yesterday about disabling or
removing it.
>
> Your named configuration looks fine to me. About the only extra items
> you might want in options are:
>
> dnssec-enable yes;
> dnssec-validation auto;
> dnssec-lookaside auto;
>
> In the ISC[*] website it says:
> - If you put “dnssec-validation auto” in named.conf, named will read
> the root key from bind.keys the first time it executes.
> - If you put “dnssec-lookaside auto” in named.conf, named will read
> the
> DLV key from bind.keys the first time it executes.
> - If you don’t have anything in named.conf and there is no bind.keys
> file, named will use the compiled in keys.
>
> so having these set as ISC suggests should mean that bind will
> automatically pick up changes to bind keys. They don't change very
> often but there are changes from time to time.
>
> [*] Internet Systems Consortium: https://www.isc.org/ - a non-profit
> that supports the Internet infrastructure. It is the source for
> downloading Root Trust Anchors, aka bind-keys.
>
Thanks for the above Martin. I'm still waiting for a query to isipp to
happen since I stopped network manager. Seems like when you're waiting
for something it never happens.
> Martin
>
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:35:00 up 1 day, 11:47, 1 user, load average: 1.05, 0.42, 0.33
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2017-09-20 at 19:39 -0500, Chris wrote:
> It was installed by default when upgrading from 14.04LTS to 16.04LTS
>
Then it may be best to just leave it there.
> I have stopped Network Manager. I've not disabled or removed it yet
> as I'm watching to see how named does the queries now.
>
I didn't suggest removing it - just following the advice from others to
change its configuration so it doesn't try to start dnsmasq or bind:
leave starting the daemons that should always be running to systemd.
Your named configuration looks fine to me. About the only extra items
you might want in options are:
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
In the ISC[*] website it says:
- If you put “dnssec-validation auto” in named.conf, named will read
the root key from bind.keys the first time it executes.
- If you put “dnssec-lookaside auto” in named.conf, named will read the
DLV key from bind.keys the first time it executes.
- If you don’t have anything in named.conf and there is no bind.keys
file, named will use the compiled in keys.
so having these set as ISC suggests should mean that bind will
automatically pick up changes to bind keys. They don't change very
often but there are changes from time to time.
[*] Internet Systems Consortium: https://www.isc.org/ - a non-profit
that supports the Internet infrastructure. It is the source for
downloading Root Trust Anchors, aka bind-keys.
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 19:05 +0100, Martin Gregorie wrote:
> On Wed, 2017-09-20 at 08:48 -0500, Chris wrote:
> >
> > On Wed, 2017-09-20 at 11:15 +0100, Martin Gregorie wrote:
> > >
> > > On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> > > >
> > > >
> > > > Hi Martin, here's what I see:
> > > >
> > > > sudo systemctl status dnsmasq
> > > > [sudo] password for chris:
> > > > ● dnsmasq.service
> > > > Loaded: not-found (Reason: No such file or directory)
> > > > Active: inactive (dead)
> > > > chris@localhost:~$ sudo systemctl enable dnsmasq
> > > > Failed to execute operation: No such file or directory
> > > > chris@localhost:~$ sudo systemctl status dnsmasq
> > > > ● dnsmasq.service
> > > > Loaded: not-found (Reason: No such file or directory)
> > > > Active: inactive (dead)
> > > >
> > > Yes, that agrees with systemd not knowing about dnsmasq.
> > >
> > > >
> > > >
> > > > I then installed dnsmasq (apparently it wasn't installed)
> > > >
> > > I don't know why you'd want to do that since you should be
> > > running
> > > named instead of dnsmasq.
> > >
> > I was tired and getting po'd at the whole mess. I installed via apt
> > then removed via apt and also ran apt purge.
> >
> > >
> > > Delete the version you just installed via the apt package manager
> > > and
> > > do a search and destroy mission to get rid of both the other copy
> > > of
> > > it
> > > and the associated configuration.
> > >
> > > Running "updatedb; locate dnsmasq" is probably the fastest way of
> > > finding it and its associated files. Anything with a similar name
> > > in
> > > /etc/init.d is probably its launcher script, so that can go too.
> > > If
> > > you
> > > have an /etc/rc.local file, check its contents because its run as
> > > part
> > > of the sysVinit process. It shouldn't have anything about dnsmasq
> > > in
> > > it
> > > but you never know...
> > >
> > From the locate command I found these - https://pastebin.com/ECjZGX
> > 1M
> >
> > I'm not sure what to do with those that are associated with
> > /snap/core.
> >
> Can't help there as I've not seen a /snap directory structure before.
> I
> don't believe any RedHat distros use it and nor does Raspbian.
>
> How was it installed in the first place? That may give you some
> clues,
> or somebody who is more familiar Debian and its clones may know a
> safe
> way to remove it: I'd be inclined to just remove the lot but then I
> tend to go in boots and all in this sort of situation. Just take a
> backup first.
It was installed by default when upgrading from 14.04LTS to 16.04LTS
>
> OTOH, since there's apparently nothing that starts dnsmasq at boot
> time
> apart from NetworkManager you can always just leave it there and
> accept
> that it will continue to occupy space on disk. Then:
>
> - do as others have said and reconfigure NetworkManager so it doesn't
> start anything.
>
I have stopped Network Manager. I've not disabled or removed it yet as
I'm watching to see how named does the queries now.
> - configure named as a recursive nameserver if that isn't already
> done
>
> - set up systemd to start named at boot time:
> systemctl enable named # This makes it start at boot time
> systemctl start named # Start it now
> systemctl status named # see if it started OK
>
It already starts at boot.
> - if it didn't like the current /etc/named.conf or it it isn't doing
> what you want, modify its configuration and:
>
> systemctl restart named # kills named and restarts it with
> the
> # new config
> systemctl status named # See what its gdoing
>
> and repeat until its right
>
>
> Martin
>
systemctl status bind9
● bind9.service - BIND Domain Name Server
Loaded: loaded (/etc/systemd/system/bind9.service; enabled; vendor
preset: enabled)
Drop-In: /run/systemd/generator/bind9.service.d
└─50-insserv.conf-$named.conf
Active: active (running) since Wed 2017-09-20 17:57:18 CDT; 3min 6s
ago
Docs: man:named(8)
Process: 19195 ExecStop=/usr/sbin/rndc stop (code=exited,
status=0/SUCCESS)
Main PID: 19203 (named)
CGroup: /system.slice/bind9.service
└─19203 /usr/sbin/named -4 -f -u bind
localhost named[19203]: automatic empty zone: EMPTY.AS112.ARPA
localhost named[19203]: configuring command channel from
'/etc/bind/rndc.key'
localhost named[19203]: command channel listening on 127.0.0.1#953
localhost named[19203]: managed-keys-zone: loaded serial 602
localhost named[19203]: zone localhost/IN: loaded serial 2
localhost named[19203]: zone 255.in-addr.arpa/IN: loaded serial 1
localhost named[19203]: zone 127.in-addr.arpa/IN: loaded serial 1
localhost named[19203]: zone 0.in-addr.arpa/IN: loaded serial 1
localhost named[19203]: all zones loaded
localhost named[19203]: running
/etc/named.conf is simply
# OPTIONS="-4 -u bind"
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
# allow-query-cache localnets;
My /etc/bind/named.conf.options reads
acl goodclients {
127.0.0.1;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
geoip-directory "/usr/share/GeoIP";
recursion yes;
allow-query { goodclients; };
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow
multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses
replacing
// the all-0's placeholder.
//forwarders {
//127.0.0.1;
//};
//dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
//listen-on-v6 { any; };
listen-on { 127.0.0.1; };
};
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
17:43:38 up 20:56, 1 user, load average: 0.05, 0.21, 0.52
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2017-09-20 at 08:48 -0500, Chris wrote:
> On Wed, 2017-09-20 at 11:15 +0100, Martin Gregorie wrote:
> > On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> > >
> > > Hi Martin, here's what I see:
> > >
> > > sudo systemctl status dnsmasq
> > > [sudo] password for chris:
> > > ● dnsmasq.service
> > > Loaded: not-found (Reason: No such file or directory)
> > > Active: inactive (dead)
> > > chris@localhost:~$ sudo systemctl enable dnsmasq
> > > Failed to execute operation: No such file or directory
> > > chris@localhost:~$ sudo systemctl status dnsmasq
> > > ● dnsmasq.service
> > > Loaded: not-found (Reason: No such file or directory)
> > > Active: inactive (dead)
> > >
> >
> > Yes, that agrees with systemd not knowing about dnsmasq.
> >
> > >
> > > I then installed dnsmasq (apparently it wasn't installed)
> > >
> >
> > I don't know why you'd want to do that since you should be running
> > named instead of dnsmasq.
> >
>
> I was tired and getting po'd at the whole mess. I installed via apt
> then removed via apt and also ran apt purge.
>
> > Delete the version you just installed via the apt package manager
> > and
> > do a search and destroy mission to get rid of both the other copy
> > of
> > it
> > and the associated configuration.
> >
> > Running "updatedb; locate dnsmasq" is probably the fastest way of
> > finding it and its associated files. Anything with a similar name
> > in
> > /etc/init.d is probably its launcher script, so that can go too. If
> > you
> > have an /etc/rc.local file, check its contents because its run as
> > part
> > of the sysVinit process. It shouldn't have anything about dnsmasq
> > in
> > it
> > but you never know...
> >
>
> From the locate command I found these - https://pastebin.com/ECjZGX1M
>
> I'm not sure what to do with those that are associated with
> /snap/core.
>
Can't help there as I've not seen a /snap directory structure before. I
don't believe any RedHat distros use it and nor does Raspbian.
How was it installed in the first place? That may give you some clues,
or somebody who is more familiar Debian and its clones may know a safe
way to remove it: I'd be inclined to just remove the lot but then I
tend to go in boots and all in this sort of situation. Just take a
backup first.
OTOH, since there's apparently nothing that starts dnsmasq at boot time
apart from NetworkManager you can always just leave it there and accept
that it will continue to occupy space on disk. Then:
- do as others have said and reconfigure NetworkManager so it doesn't
start anything.
- configure named as a recursive nameserver if that isn't already done
- set up systemd to start named at boot time:
systemctl enable named # This makes it start at boot time
systemctl start named # Start it now
systemctl status named # see if it started OK
- if it didn't like the current /etc/named.conf or it it isn't doing
what you want, modify its configuration and:
systemctl restart named # kills named and restarts it with
the
# new config
systemctl status named # See what its gdoing
and repeat until its right
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 20 Sep 2017, at 9:48, Chris wrote:
> From the locate command I found these - https://pastebin.com/ECjZGX1M
AHA!
Apparently Ubuntu (and Debian?) has a package called "dnsmasq-base" which is installed as a dependency of libvirt, which manages it independently and autocratically...
2 maybe useful links:
https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Tell_systemd-resolved_to_use_libvirt.27s_dnsmasq_for_VMs_only_.2817.04.2B-.29
https://help.ubuntu.com/community/Dnsmasq
In short: this looks like a platform-specific situation grounded in trying to use one system for both spam filtering and running virtual machines.
> I'm not sure what to do with those that are associated with /snap/core.
No idea. Looks like an Ubuntuism I am unfamiliar with.
> There's nothing in /etc/init.d for dnsmasq.
No, there wouldn't be. THIS dnsmasq is libvirtd's pet. It should be irrelevant to your SpamAssassin resolution issues. As long as BIND's 'named' process is binding to 127.0.0.1:53 before dnsmasq tries to do so, you should only need to look at what named is doing.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 11:15 +0100, Martin Gregorie wrote:
> On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> >
> > Hi Martin, here's what I see:
> >
> > sudo systemctl status dnsmasq
> > [sudo] password for chris:
> > ● dnsmasq.service
> > Loaded: not-found (Reason: No such file or directory)
> > Active: inactive (dead)
> > chris@localhost:~$ sudo systemctl enable dnsmasq
> > Failed to execute operation: No such file or directory
> > chris@localhost:~$ sudo systemctl status dnsmasq
> > ● dnsmasq.service
> > Loaded: not-found (Reason: No such file or directory)
> > Active: inactive (dead)
> >
> Yes, that agrees with systemd not knowing about dnsmasq.
>
> >
> > I then installed dnsmasq (apparently it wasn't installed)
> >
> I don't know why you'd want to do that since you should be running
> named instead of dnsmasq.
>
I was tired and getting po'd at the whole mess. I installed via apt
then removed via apt and also ran apt purge.
> Delete the version you just installed via the apt package manager and
> do a search and destroy mission to get rid of both the other copy of
> it
> and the associated configuration.
>
> Running "updatedb; locate dnsmasq" is probably the fastest way of
> finding it and its associated files. Anything with a similar name in
> /etc/init.d is probably its launcher script, so that can go too. If
> you
> have an /etc/rc.local file, check its contents because its run as
> part
> of the sysVinit process. It shouldn't have anything about dnsmasq in
> it
> but you never know...
>
From the locate command I found these - https://pastebin.com/ECjZGX1M
I'm not sure what to do with those that are associated with /snap/core.
There's nothing in /etc/init.d for dnsmasq.
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:07:59 up 11:20, 1 user, load average: 0.08, 0.07, 0.08
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> Hi Martin, here's what I see:
>
> sudo systemctl status dnsmasq
> [sudo] password for chris:
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
> chris@localhost:~$ sudo systemctl enable dnsmasq
> Failed to execute operation: No such file or directory
> chris@localhost:~$ sudo systemctl status dnsmasq
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
>
Yes, that agrees with systemd not knowing about dnsmasq.
> I then installed dnsmasq (apparently it wasn't installed)
>
I don't know why you'd want to do that since you should be running
named instead of dnsmasq.
Delete the version you just installed via the apt package manager and
do a search and destroy mission to get rid of both the other copy of it
and the associated configuration.
Running "updatedb; locate dnsmasq" is probably the fastest way of
finding it and its associated files. Anything with a similar name in
/etc/init.d is probably its launcher script, so that can go too. If you
have an /etc/rc.local file, check its contents because its run as part
of the sysVinit process. It shouldn't have anything about dnsmasq in it
but you never know...
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
> >
> > On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
> > >
> > >
> > >
> > > Thanks Martin, here's what I get, it appears to not be running.
> > >
> > > sudo systemctl stop dnsmasq
> > > [sudo] password for chris:
> > > Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
> > >
> > OK, that makes sense
> >
> > >
> > >
> > > sudo systemctl disable dnsmasq
> > > Failed to execute operation: No such file or directory
> > >
> > That's interesting: I've never seen that before:
> >
> > Here's what I see of I enable dnsmasq, check its status, disable it
> > and
> > check status again:
> >
> > $ sudo systemctl enable dnsmasq
> > Created symlink /etc/systemd/system/multi-
> > user.target.wants/dnsmasq.service →
> > /usr/lib/systemd/system/dnsmasq.service.
> >
> > $ sudo systemctl status dnsmasq
> > ● dnsmasq.service - DNS caching server.
> > Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
> > enabled;
> > vendor preset: disabled)
> > Active: inactive (dead)
> >
> > $ sudo systemctl disable dnsmasq
> > Removed /etc/systemd/system/multi-
> > user.target.wants/dnsmasq.service.
> >
> > $ sudo systemctl status dnsmasq
> > ● dnsmasq.service - DNS caching server.
> > Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
> > disabled;
> > vendor preset: disabled)
> > Active: inactive (dead)
> >
> > This is a Fedora 25 system which I use, amongst other things, as my
> > SA
> > and test system. My live Postfix and SA are on another system which
> > runs named. I don't use dnsmasq at all but it turns out to be part
> > of
> > the standard software installed by F25.
> >
> > It would be interesting to know what 'systemctl status' shows on
> > your
> > system, though its quite possible it looks similar to what
> > 'systemctl
> > disable' showed. I can only guess that your system is a
> > transitional
> > systemd setup, i.e. systemctl is used for service management but
> > some
> > services (dnsmasq for one) are still running under the old systemV
> > init
> > scripts. Fedora installations used to work that way for some
> > services,
> > but that was a few versions ago (F21 or 22 at the latest).
> >
> >
> > Martin
> >
> Hi Martin, here's what I see:
>
> sudo systemctl status dnsmasq
> [sudo] password for chris:
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
> chris@localhost:~$ sudo systemctl enable dnsmasq
> Failed to execute operation: No such file or directory
> chris@localhost:~$ sudo systemctl status dnsmasq
> ● dnsmasq.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
>
> I then installed dnsmasq (apparently it wasn't installed)
>
> Results are here - https://pastebin.com/MRR4NCMp
After a restart - status now shows:
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor
preset: enabled)
Drop-In: /run/systemd/generator/dnsmasq.service.d
└─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
Active: active (running) since Tue 2017-09-19 19:56:46 CDT; 4min 11s
ago
Process: 1215 ExecStartPost=/etc/init.d/dnsmasq systemd-start-
resolvconf (code=exited, status=0/SUCCESS)
Process: 1040 ExecStart=/etc/init.d/dnsmasq systemd-exec
(code=exited, status=0/SUCCESS)
Process: 963 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited,
status=0/SUCCESS)
Main PID: 1214 (dnsmasq)
CGroup: /system.slice/dnsmasq.service
└─1214 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u
dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-
dist,.dpkg-old,.dpkg-new --local-service --trust-a
Sep 19 19:56:40 localhost dnsmasq[963]: dnsmasq: syntax check OK.
Sep 19 19:56:46 localhost dnsmasq[1214]: started, version 2.75
cachesize 150
Sep 19 19:56:46 localhost dnsmasq[1214]: compile time options: IPv6
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
DNSSEC loop-detect inotify
Sep 19 19:56:46 localhost dnsmasq[1214]: no servers found in
/var/run/dnsmasq/resolv.conf, will retry
Sep 19 19:56:46 localhost dnsmasq[1214]: read /etc/hosts - 6 addresses
Sep 19 19:56:46 localhost systemd[1]: Started dnsmasq - A lightweight
DHCP and caching DNS server.
Sep 19 19:57:05 localhost dnsmasq[1214]: reading
/var/run/dnsmasq/resolv.conf
Sep 19 19:57:05 localhost dnsmasq[1214]: using nameserver
192.168.0.1#53
Sep 19 19:57:05 localhost dnsmasq[1214]: using nameserver
205.171.2.226#53
Sep 19 19:57:05 localhost dnsmasq[1214]: ignoring nameserver 127.0.0.1
- local interface
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
20:01:58 up 6 min, 1 user, load average: 5.08, 5.51, 2.71
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 23:04 -0400, Bill Cole wrote:
> On 19 Sep 2017, at 22:36, Chris wrote:
>
> >
> > On Wed, 2017-09-20 at 04:31 +0200, Reindl Harald wrote:
> > >
> > >
> > > Am 20.09.2017 um 02:32 schrieb Chris:
> > > >
> > > >
> > > > I then installed dnsmasq (apparently it wasn't installed)
> > > frankly clean up your mess - you recently posted dnsmasq as well
> > > as
> > > named listening on different interfaces for DNS, now you say
> > > dnsmasq
> > > was
> > > not installed
> > Will do, sorry for all the noise the last few days. I'll see if I
> > can
> > figure this out myself.
> Everyone here started clueless and when we obtained a little
> knowledge, got dangerous: mostly to ourselves. No apologies needed.
Thanks Bill, I guess in my 68yrs I've really gotten dangerous.
>
> You have clearly done something on your system that confuse the
> specific problem you're having with SpamAssassin. I suspect the root
> issue is installing dnsmasq from the upstream source distribution
> (and maybe BIND also?) rather than using the Debian/Ubuntu package(s)
> via the apt and/or dpkg tools. That's not an uncommon class of
> mistake, but it is an especially risky move on a systemd-managed
> platform and especially on anything Debian-based because Debian makes
> substantial changes to some open source software which can cause
> unusual problems which are unique to the platform. The bottom line:
> on Ubuntu, use the Ubuntu software installation tools and do not try
> to install anything from upstream source that has a Ubuntu package.
>
Both BIND and last night dnsmasq were installed via apt and dnsmasq was
removed via apt remove and apt purge. In fact I make it a point to
install packages via apt unless it can't be helped such as the beta of
fetchmail I'm currently running. The odd/bad thing about this whole
mess is that the issue of queries to isipp and bb.barracuda have been
going on for quite awhile now. I just finally decided to try and do
something about it. The issue with the isipp query going to the
incorrect ip only started a few days ago though.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:49:39 up 12:02, 1 user, load average: 2.38, 1.31, 0.93
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Sep 2017, at 22:36, Chris wrote:
> On Wed, 2017-09-20 at 04:31 +0200, Reindl Harald wrote:
>>
>> Am 20.09.2017 um 02:32 schrieb Chris:
>>>
>>> I then installed dnsmasq (apparently it wasn't installed)
>> frankly clean up your mess - you recently posted dnsmasq as well as
>> named listening on different interfaces for DNS, now you say dnsmasq
>> was
>> not installed
>
> Will do, sorry for all the noise the last few days. I'll see if I can
> figure this out myself.
Everyone here started clueless and when we obtained a little knowledge, got dangerous: mostly to ourselves. No apologies needed.
You have clearly done something on your system that confuse the specific problem you're having with SpamAssassin. I suspect the root issue is installing dnsmasq from the upstream source distribution (and maybe BIND also?) rather than using the Debian/Ubuntu package(s) via the apt and/or dpkg tools. That's not an uncommon class of mistake, but it is an especially risky move on a systemd-managed platform and especially on anything Debian-based because Debian makes substantial changes to some open source software which can cause unusual problems which are unique to the platform. The bottom line: on Ubuntu, use the Ubuntu software installation tools and do not try to install anything from upstream source that has a Ubuntu package.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 04:31 +0200, Reindl Harald wrote:
>
> Am 20.09.2017 um 02:32 schrieb Chris:
> >
> > I then installed dnsmasq (apparently it wasn't installed)
> frankly clean up your mess - you recently posted dnsmasq as well as
> named listening on different interfaces for DNS, now you say dnsmasq
> was
> not installed
Will do, sorry for all the noise the last few days. I'll see if I can
figure this out myself.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
21:35:17 up 48 min, 1 user, load average: 0.58, 0.39, 0.38
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
> On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
> >
> >
> > Thanks Martin, here's what I get, it appears to not be running.
> >
> > sudo systemctl stop dnsmasq
> > [sudo] password for chris:
> > Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
> >
> OK, that makes sense
>
> >
> > sudo systemctl disable dnsmasq
> > Failed to execute operation: No such file or directory
> >
> That's interesting: I've never seen that before:
>
> Here's what I see of I enable dnsmasq, check its status, disable it
> and
> check status again:
>
> $ sudo systemctl enable dnsmasq
> Created symlink /etc/systemd/system/multi-
> user.target.wants/dnsmasq.service →
> /usr/lib/systemd/system/dnsmasq.service.
>
> $ sudo systemctl status dnsmasq
> ● dnsmasq.service - DNS caching server.
> Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled;
> vendor preset: disabled)
> Active: inactive (dead)
>
> $ sudo systemctl disable dnsmasq
> Removed /etc/systemd/system/multi-user.target.wants/dnsmasq.service.
>
> $ sudo systemctl status dnsmasq
> ● dnsmasq.service - DNS caching server.
> Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled;
> vendor preset: disabled)
> Active: inactive (dead)
>
> This is a Fedora 25 system which I use, amongst other things, as my
> SA
> and test system. My live Postfix and SA are on another system which
> runs named. I don't use dnsmasq at all but it turns out to be part of
> the standard software installed by F25.
>
> It would be interesting to know what 'systemctl status' shows on your
> system, though its quite possible it looks similar to what 'systemctl
> disable' showed. I can only guess that your system is a transitional
> systemd setup, i.e. systemctl is used for service management but some
> services (dnsmasq for one) are still running under the old systemV
> init
> scripts. Fedora installations used to work that way for some
> services,
> but that was a few versions ago (F21 or 22 at the latest).
>
>
> Martin
>
Hi Martin, here's what I see:
sudo systemctl status dnsmasq
[sudo] password for chris:
● dnsmasq.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
chris@localhost:~$ sudo systemctl enable dnsmasq
Failed to execute operation: No such file or directory
chris@localhost:~$ sudo systemctl status dnsmasq
● dnsmasq.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
I then installed dnsmasq (apparently it wasn't installed)
Results are here - https://pastebin.com/MRR4NCMp
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
19:25:14 up 1 day, 3:04, 2 users, load average: 0.37, 0.26, 0.19
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
>
> Thanks Martin, here's what I get, it appears to not be running.
>
> sudo systemctl stop dnsmasq
> [sudo] password for chris:
> Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
>
OK, that makes sense
> sudo systemctl disable dnsmasq
> Failed to execute operation: No such file or directory
>
That's interesting: I've never seen that before:
Here's what I see of I enable dnsmasq, check its status, disable it and
check status again:
$ sudo systemctl enable dnsmasq
Created symlink /etc/systemd/system/multi-
user.target.wants/dnsmasq.service →
/usr/lib/systemd/system/dnsmasq.service.
$ sudo systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled;
vendor preset: disabled)
Active: inactive (dead)
$ sudo systemctl disable dnsmasq
Removed /etc/systemd/system/multi-user.target.wants/dnsmasq.service.
$ sudo systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled;
vendor preset: disabled)
Active: inactive (dead)
This is a Fedora 25 system which I use, amongst other things, as my SA
and test system. My live Postfix and SA are on another system which
runs named. I don't use dnsmasq at all but it turns out to be part of
the standard software installed by F25.
It would be interesting to know what 'systemctl status' shows on your
system, though its quite possible it looks similar to what 'systemctl
disable' showed. I can only guess that your system is a transitional
systemd setup, i.e. systemctl is used for service management but some
services (dnsmasq for one) are still running under the old systemV init
scripts. Fedora installations used to work that way for some services,
but that was a few versions ago (F21 or 22 at the latest).
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 22:07 +0100, Martin Gregorie wrote:
> On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > I've disable dnsmasq in my
> > > > > > > /etc/NetworkManager/NetworkManager.conf
> > via
> > #dns=dnsmasq
> >
> > However, when restarting the network I see:
> > dnsmasq[2323]: reading /etc/resolv.conf
> > dnsmasq[2323]: using nameserver 127.0.0.1#53
> > dnsmasq[2323]: using nameserver 127.0.0.1#53
> >
> > NetworkManager[24113]: <info> [1505852393.3238] nameserver
> > '192.168.0.1'
> > NetworkManager[24113]: <info> [1505852393.3238] nameserver
> > '205.171.2.226'
> >
> If you want dnsmasq dead and assuming you're using systemd, do this:
>
> sudo systemctl stop dnsmasq
> sudo systemctl disable dnsmasq
>
> ...then it won't be restarted under any circumstances including a
> reboot.
>
> If you're still on the old sysVinit system, do its equivalent so that
> dnsmasq isn't started at any runlevel.
>
>
> Martin
>
Thanks Martin, here's what I get, it appears to not be running.
sudo systemctl stop dnsmasq
[sudo] password for chris:
Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
sudo systemctl disable dnsmasq
Failed to execute operation: No such file or directory
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:33:34 up 1 day, 12 min, 1 user, load average: 0.28, 0.46, 0.76
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:
> > > > > > I've disable dnsmasq in my
> > > > > > /etc/NetworkManager/NetworkManager.conf
> via
> #dns=dnsmasq
>
> However, when restarting the network I see:
> dnsmasq[2323]: reading /etc/resolv.conf
> dnsmasq[2323]: using nameserver 127.0.0.1#53
> dnsmasq[2323]: using nameserver 127.0.0.1#53
>
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '192.168.0.1'
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '205.171.2.226'
>
If you want dnsmasq dead and assuming you're using systemd, do this:
sudo systemctl stop dnsmasq
sudo systemctl disable dnsmasq
...then it won't be restarted under any circumstances including a
reboot.
If you're still on the old sysVinit system, do its equivalent so that
dnsmasq isn't started at any runlevel.
Martin
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:
> On Tue, 2017-09-19 at 08:41 -0500, David Jones wrote:
> >
> > On 09/19/2017 08:25 AM, Chris wrote:
> > >
> > >
> > > On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> > > >
> > > >
> > > > On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 09/18/2017 06:03 PM, Chris wrote:
> > > > [snip]
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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, here's my output. I ran as sudo to see all inclusive:
> > > >
> > > > sudo netstat -tunlap | grep ":53"
> > > > [sudo] password for chris:
> > > > tcp 0 0
> > > > 192.168.122.1:53 0.0.0.0:* LISTEN 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > tcp 0 0
> > > > 127.0.1.1:53 0.0.0.0:* LISTEN 131
> > > > 6/
> > > > dnsm
> > > > as
> > > > q
> > > > tcp 0 0
> > > > 192.168.0.51:53 0.0.0.0:* LISTEN 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > tcp 0 0
> > > > 127.0.0.1:53 0.0.0.0:* LISTEN 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 1 1
> > > > 192.168.0.51:33475 198.97.190.53:53 CLOSING -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 0 0
> > > > 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
> > > >
> > > >
> > > > tcp 1 1
> > > > 192.168.0.51:40633 198.97.190.53:53 CLOSING -
> > > >
> > > >
> > > > udp 0 0
> > > > 192.168.122.1:53 0.0.0.0:* 232
> > > > 3/
> > > > dnsm
> > > > as
> > > > q
> > > > udp 0 0
> > > > 192.168.122.1:53 0.0.0.0:* 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > udp 0 0
> > > > 127.0.1.1:53 0.0.0.0:* 131
> > > > 6/
> > > > dnsm
> > > > as
> > > > q
> > > > udp 0 0
> > > > 192.168.0.51:53 0.0.0.0:* 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > udp 0 0
> > > > 127.0.0.1:53 0.0.0.0:* 124
> > > > 5/
> > > > name
> > > > d
> > > >
> > > > udp 0 0
> > > > 0.0.0.0:5353 0.0.0.0:* 153
> > > > 3/
> > > > snap
> > > > we
> > > > b
> > > > udp 0 0
> > > > 0.0.0.0:5353 0.0.0.0:* 100
> > > > 4/
> > > > avah
> > > > i-
> > > > daemon:
> > > > udp6 0 0
> > > > :::5353 :::* 153
> > > > 3/
> > > > snap
> > > > we
> > > > b
> > > > udp6 0 0
> > > > :::5353 :::* 100
> > > > 4/
> > > > avah
> > > > i-
> > > > daemon:
> > > >
> > > I neglected to insert my /etc/bind/named.conf.options file
> > >
> > > acl goodclients {
> > > 127.0.0.1;
> > > localhost;
> > > localnets;
> > > };
> > >
> > > options {
> > > directory "/var/cache/bind";
> > > geoip-directory "/usr/share/GeoIP";
> > >
> > > recursion yes;
> > > allow-query { goodclients; };
> > >
> > > tcp 0 0 127.0.0.1:53
> > > // If there is a firewall between you and nameservers you want
> > > // to talk to, you may need to fix the firewall to allow
> > > multiple
> > > // ports to talk. See http://www.kb.cert.org/vuls/id/800113
> > >
> > > // If your ISP provided one or more IP addresses for stable
> > > // nameservers, you probably want to use them as forwarders.
> > > // Uncomment the following block, and insert the addresses
> > > replacing
> > > // the all-0's placeholder.
> > >
> > > //forwarders {
> > > //127.0.0.1;
> > > //};
> > >
> > > //=============================================================
> > > ===========
> > > // If BIND logs error messages about the root key being
> > > expired,
> > > // you will need to update your keys. See https://www.isc.org/
> > > bind-keys
> > > //=============================================================
> > > ===========
> > > //dnssec-validation auto;
> > >
> > > auth-nxdomain no; # conform to RFC1035
> > > //listen-on-v6 { any; };
> > > listen-on { any; };
> > > };
> > >
> > Change this in the named.conf.options and BIND should be fine:
> >
> > listen-on { 127.0.0.1; };
> >
> > Uninstall dnsmasq and make sure it's no longer listening on
> > 127.0.1.1:53
> > just to keep things simple.
> >
> > Your /etc/resolv.conf should be pointed to 127.0.0.1 which is
> > should
> > already be based on the dig +trace output.
> >
> > Now check your logs to see if you are still getting odd queries to
> > destinations that aren't authoritative DNS servers which are being
> > refused. Use dig +trace to check responses which should match the
> > http://multirbl.valli.org site responses for that particular RBL
> > or
> > whitelist excluding IVM which is a subscription-based RBL.
> >
> Here's the output now of the dig +trace
> tcp 0 0
> 127.0.0.1:53 0.0.0.0:* LISTEN -
>
>
> tcp 0 0
> 127.0.1.1:53 0.0.0.0:* LISTEN -
>
>
> udp 0 0
> 127.0.0.1:53 0.0.0.0:* -
>
>
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* -
>
>
> udp 0 0
> 127.0.1.1:53 0.0.0.0:* -
>
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* -
>
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* -
>
>
> udp6 0 0
> :::5353 :::* -
>
>
> udp6 0 0
> :::5353 :::* -
>
> I'm getting different outputs each time I run dig +trace
> 65.43.116.208.iadb.isipp.com
>
> 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
> 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.0.1
> 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.2.255.4
> 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
> ;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in
> 67
> ms
>
> 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.3.100.10
> 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.1
> 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.2.255.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.101.201.10
> 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
> iadb.isipp.com. 172800 IN NS ns2.
> ns
> .isipp.com.
> iadb.isipp.com. 172800 IN NS b.au
> th
> -ns.sonic.net.
> iadb.isipp.com. 172800 IN NS a.au
> th
> -ns.sonic.net.
> iadb.isipp.com. 172800 IN NS ns2.
> pr
> gmr.com.
> iadb.isipp.com. 172800 IN NS ns01
> .b
> ackupdns.com.
> iadb.isipp.com. 172800 IN NS c.au
> th
> -ns.sonic.net.
> iadb.isipp.com. 172800 IN NS ns1.
> ns
> .isipp.com.
> ;; Received 390 bytes from 67.227.190.38#53(ns1.ns.isipp.com) in 55
> ms
>
> I've disable dnsmasq in my /etc/NetworkManager/NetworkManager.conf
> via
> #dns=dnsmasq
>
> However, when restarting the network I see:
> dnsmasq[2323]: reading /etc/resolv.conf
> dnsmasq[2323]: using nameserver 127.0.0.1#53
> dnsmasq[2323]: using nameserver 127.0.0.1#53
>
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '192.168.0.1'
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '205.171.2.226'
>
> Unfortunately so far today since I've started trying to work this out
> there have been no queries to isipp by SA. I'll have to see what
> happens when there is one.
>
> I think David I may just be confusing myself more, at least the
> network
> is still up.
>
A reply to self,
named[8076]: REFUSED unexpected RCODE resolving
'ns2.ns.isipp.com/A/IN': 168.150.251.35#53
named[8076]: REFUSED unexpected RCODE resolving
'ns1.ns.isipp.com/A/IN': 168.150.251.35#53
Still seeing this
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:44:32 up 1 day, 23 min, 1 user, load average: 0.73, 0.60, 0.66
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 14:47 -0700, John Hardin wrote:
> On Tue, 19 Sep 2017, Chris wrote:
>
> > I'm getting different outputs each time I run dig +trace
> > 65.43.116.208.iadb.isipp.com
> >
> > 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
> > 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.0.1
> > 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.2.255.4
> > 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
> > ;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in
> 67
> > ms
> >
> > 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.3.100.10
> > 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.1
> > 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.2.255.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.101.201.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
>
> That just looks like sorting.
> Today: Talk Like a Pirate day
Aargh, I guess that makes sense
Thanks
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
17:08:56 up 1 day, 48 min, 1 user, load average: 1.37, 1.07, 0.84
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by John Hardin <jh...@impsec.org>.
On Tue, 19 Sep 2017, Chris wrote:
> I'm getting different outputs each time I run dig +trace
> 65.43.116.208.iadb.isipp.com
>
> 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
> 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.0.1
> 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.2.255.4
> 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
> ;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in 67
> ms
>
> 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.3.100.10
> 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.1
> 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.2.255.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.101.201.10
> 65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
That just looks like sorting.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Programming is an art form that fights back. -- Kevin S. Gallagher
-----------------------------------------------------------------------
Today: Talk Like a Pirate day
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Sep 2017, at 16:40, Chris wrote:
> Here's the output now of the dig +trace
> tcp 0 0
> 127.0.0.1:53 0.0.0.0:* LISTEN -
>
> tcp 0 0
> 127.0.1.1:53 0.0.0.0:* LISTEN -
>
> udp 0 0
> 127.0.0.1:53 0.0.0.0:* -
>
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* -
>
> udp 0 0
> 127.0.1.1:53 0.0.0.0:* -
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* -
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* -
>
> udp6 0 0
> :::5353 :::* -
>
> udp6 0 0
> :::5353 :::*
That's netstat output and without the 'p' option it's not very enlightening. Also, grepping for ":53 " instead of ":53" will avoid getting the mDNS (5353) listeners. Weird to see those on a non-Mac, but I guess avahi is harmless...
> I'm getting different outputs each time I run dig +trace
As you should, for any name in a zone with multiple authoritative nameservers.
[...]
> I've disable dnsmasq in my /etc/NetworkManager/NetworkManager.conf via
> #dns=dnsmasq
>
> However, when restarting the network I see:
> dnsmasq[2323]: reading /etc/resolv.conf
> dnsmasq[2323]: using nameserver 127.0.0.1#53
> dnsmasq[2323]: using nameserver 127.0.0.1#53
>
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '192.168.0.1'
> NetworkManager[24113]: <info> [1505852393.3238] nameserver
> '205.171.2.226'
If you insist on using NetworkMangler, "dns=none" is better.
Also, that's NOT how you disable dnsmasq. That just tells NetworkMangler how exactly to screw up resolv.conf. It is documented in the NetworkManager.conf man page...
Since this is a modern Ubuntu, dnsmasq is managed by systemd, so you need to do something like:
systemctl stop dnsmasq
systemctl disable dnsmasq
And probably:
apt-get purge dnsmasq
> Unfortunately so far today since I've started trying to work this out
> there have been no queries to isipp by SA. I'll have to see what
> happens when there is one.
>
> I think David I may just be confusing myself more, at least the network
> is still up.
Then I guess a recommendation to also remove BIND and just install Unbound (a less complex recursive resolver daemon) instead would be unwelcome...
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 08:41 -0500, David Jones wrote:
> On 09/19/2017 08:25 AM, Chris wrote:
> >
> > On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> > >
> > > On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> > > >
> > > >
> > > > On 09/18/2017 06:03 PM, Chris wrote:
> > > [snip]
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > 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, here's my output. I ran as sudo to see all inclusive:
> > >
> > > sudo netstat -tunlap | grep ":53"
> > > [sudo] password for chris:
> > > tcp 0 0
> > > 192.168.122.1:53 0.0.0.0:* LISTEN 1245/
> > > name
> > > d
> > >
> > > tcp 0 0
> > > 127.0.1.1:53 0.0.0.0:* LISTEN 1316/
> > > dnsm
> > > as
> > > q
> > > tcp 0 0
> > > 192.168.0.51:53 0.0.0.0:* LISTEN 1245/
> > > name
> > > d
> > >
> > > tcp 0 0
> > > 127.0.0.1:53 0.0.0.0:* LISTEN 1245/
> > > name
> > > d
> > >
> > > tcp 0 0
> > > 192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 1 1
> > > 192.168.0.51:33475 198.97.190.53:53 CLOSING -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
> > >
> > >
> > > tcp 0 0
> > > 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
> > >
> > >
> > > tcp 1 1
> > > 192.168.0.51:40633 198.97.190.53:53 CLOSING -
> > >
> > >
> > > udp 0 0
> > > 192.168.122.1:53 0.0.0.0:* 2323/
> > > dnsm
> > > as
> > > q
> > > udp 0 0
> > > 192.168.122.1:53 0.0.0.0:* 1245/
> > > name
> > > d
> > >
> > > udp 0 0
> > > 127.0.1.1:53 0.0.0.0:* 1316/
> > > dnsm
> > > as
> > > q
> > > udp 0 0
> > > 192.168.0.51:53 0.0.0.0:* 1245/
> > > name
> > > d
> > >
> > > udp 0 0
> > > 127.0.0.1:53 0.0.0.0:* 1245/
> > > name
> > > d
> > >
> > > udp 0 0
> > > 0.0.0.0:5353 0.0.0.0:* 1533/
> > > snap
> > > we
> > > b
> > > udp 0 0
> > > 0.0.0.0:5353 0.0.0.0:* 1004/
> > > avah
> > > i-
> > > daemon:
> > > udp6 0 0
> > > :::5353 :::* 1533/
> > > snap
> > > we
> > > b
> > > udp6 0 0
> > > :::5353 :::* 1004/
> > > avah
> > > i-
> > > daemon:
> > >
> > I neglected to insert my /etc/bind/named.conf.options file
> >
> > acl goodclients {
> > 127.0.0.1;
> > localhost;
> > localnets;
> > };
> >
> > options {
> > directory "/var/cache/bind";
> > geoip-directory "/usr/share/GeoIP";
> >
> > recursion yes;
> > allow-query { goodclients; };
> >
> > tcp 0 0 127.0.0.1:53
> > // If there is a firewall between you and nameservers you want
> > // to talk to, you may need to fix the firewall to allow
> > multiple
> > // ports to talk. See http://www.kb.cert.org/vuls/id/800113
> >
> > // If your ISP provided one or more IP addresses for stable
> > // nameservers, you probably want to use them as forwarders.
> > // Uncomment the following block, and insert the addresses
> > replacing
> > // the all-0's placeholder.
> >
> > //forwarders {
> > //127.0.0.1;
> > //};
> >
> > //=============================================================
> > ===========
> > // If BIND logs error messages about the root key being
> > expired,
> > // you will need to update your keys. See https://www.isc.org/
> > bind-keys
> > //=============================================================
> > ===========
> > //dnssec-validation auto;
> >
> > auth-nxdomain no; # conform to RFC1035
> > //listen-on-v6 { any; };
> > listen-on { any; };
> > };
> >
> Change this in the named.conf.options and BIND should be fine:
>
> listen-on { 127.0.0.1; };
>
> Uninstall dnsmasq and make sure it's no longer listening on
> 127.0.1.1:53
> just to keep things simple.
>
> Your /etc/resolv.conf should be pointed to 127.0.0.1 which is should
> already be based on the dig +trace output.
>
> Now check your logs to see if you are still getting odd queries to
> destinations that aren't authoritative DNS servers which are being
> refused. Use dig +trace to check responses which should match the
> http://multirbl.valli.org site responses for that particular RBL or
> whitelist excluding IVM which is a subscription-based RBL.
>
Here's the output now of the dig +trace
tcp 0 0
127.0.0.1:53 0.0.0.0:* LISTEN -
tcp 0 0
127.0.1.1:53 0.0.0.0:* LISTEN -
udp 0 0
127.0.0.1:53 0.0.0.0:* -
udp 0 0
192.168.122.1:53 0.0.0.0:* -
udp 0 0
127.0.1.1:53 0.0.0.0:* -
udp 0 0
0.0.0.0:5353 0.0.0.0:* -
udp 0 0
0.0.0.0:5353 0.0.0.0:* -
udp6 0 0
:::5353 :::* -
udp6 0 0
:::5353 :::* -
I'm getting different outputs each time I run dig +trace
65.43.116.208.iadb.isipp.com
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
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.0.1
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.2.255.4
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
;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in 67
ms
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.3.100.10
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.1
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.2.255.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.101.201.10
65.43.116.208.iadb.isipp.com. 3600 IN A 127.0.1.255
iadb.isipp.com. 172800 IN NS ns2.ns
.isipp.com.
iadb.isipp.com. 172800 IN NS b.auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS a.auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS ns2.pr
gmr.com.
iadb.isipp.com. 172800 IN NS ns01.b
ackupdns.com.
iadb.isipp.com. 172800 IN NS c.auth
-ns.sonic.net.
iadb.isipp.com. 172800 IN NS ns1.ns
.isipp.com.
;; Received 390 bytes from 67.227.190.38#53(ns1.ns.isipp.com) in 55 ms
I've disable dnsmasq in my /etc/NetworkManager/NetworkManager.conf via
#dns=dnsmasq
However, when restarting the network I see:
dnsmasq[2323]: reading /etc/resolv.conf
dnsmasq[2323]: using nameserver 127.0.0.1#53
dnsmasq[2323]: using nameserver 127.0.0.1#53
NetworkManager[24113]: <info> [1505852393.3238] nameserver
'192.168.0.1'
NetworkManager[24113]: <info> [1505852393.3238] nameserver
'205.171.2.226'
Unfortunately so far today since I've started trying to work this out
there have been no queries to isipp by SA. I'll have to see what
happens when there is one.
I think David I may just be confusing myself more, at least the network
is still up.
-
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
11:32:46 up 19:12, 1 user, load average: 0.43, 0.54, 0.43
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
On 09/19/2017 08:25 AM, Chris wrote:
> On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
>> On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
>>>
>>> On 09/18/2017 06:03 PM, Chris wrote:
>> [snip]
>>>
>>>>
>>>>
>>>> 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, here's my output. I ran as sudo to see all inclusive:
>>
>> sudo netstat -tunlap | grep ":53"
>> [sudo] password for chris:
>> tcp 0 0
>> 192.168.122.1:53 0.0.0.0:* LISTEN 1245/name
>> d
>>
>> tcp 0 0
>> 127.0.1.1:53 0.0.0.0:* LISTEN 1316/dnsm
>> as
>> q
>> tcp 0 0
>> 192.168.0.51:53 0.0.0.0:* LISTEN 1245/name
>> d
>>
>> tcp 0 0
>> 127.0.0.1:53 0.0.0.0:* LISTEN 1245/name
>> d
>>
>> tcp 0 0
>> 192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
>>
>>
>> tcp 1 1
>> 192.168.0.51:33475 198.97.190.53:53 CLOSING -
>>
>>
>> tcp 0 0
>> 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
>>
>>
>> tcp 0 0
>> 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
>>
>>
>> tcp 1 1
>> 192.168.0.51:40633 198.97.190.53:53 CLOSING -
>>
>>
>> udp 0 0
>> 192.168.122.1:53 0.0.0.0:* 2323/dnsm
>> as
>> q
>> udp 0 0
>> 192.168.122.1:53 0.0.0.0:* 1245/name
>> d
>>
>> udp 0 0
>> 127.0.1.1:53 0.0.0.0:* 1316/dnsm
>> as
>> q
>> udp 0 0
>> 192.168.0.51:53 0.0.0.0:* 1245/name
>> d
>>
>> udp 0 0
>> 127.0.0.1:53 0.0.0.0:* 1245/name
>> d
>>
>> udp 0 0
>> 0.0.0.0:5353 0.0.0.0:* 1533/snap
>> we
>> b
>> udp 0 0
>> 0.0.0.0:5353 0.0.0.0:* 1004/avah
>> i-
>> daemon:
>> udp6 0 0
>> :::5353 :::* 1533/snap
>> we
>> b
>> udp6 0 0
>> :::5353 :::* 1004/avah
>> i-
>> daemon:
>>
>
> I neglected to insert my /etc/bind/named.conf.options file
>
> acl goodclients {
> 127.0.0.1;
> localhost;
> localnets;
> };
>
> options {
> directory "/var/cache/bind";
> geoip-directory "/usr/share/GeoIP";
>
> recursion yes;
> allow-query { goodclients; };
>
>
> // If there is a firewall between you and nameservers you want
> // to talk to, you may need to fix the firewall to allow
> multiple
> // ports to talk. See http://www.kb.cert.org/vuls/id/800113
>
> // If your ISP provided one or more IP addresses for stable
> // nameservers, you probably want to use them as forwarders.
> // Uncomment the following block, and insert the addresses
> replacing
> // the all-0's placeholder.
>
> //forwarders {
> //127.0.0.1;
> //};
>
> //=============================================================
> ===========
> // If BIND logs error messages about the root key being
> expired,
> // you will need to update your keys. See https://www.isc.org/
> bind-keys
> //=============================================================
> ===========
> //dnssec-validation auto;
>
> auth-nxdomain no; # conform to RFC1035
> //listen-on-v6 { any; };
> listen-on { any; };
> };
>
Change this in the named.conf.options and BIND should be fine:
listen-on { 127.0.0.1; };
Uninstall dnsmasq and make sure it's no longer listening on 127.0.1.1:53
just to keep things simple.
Your /etc/resolv.conf should be pointed to 127.0.0.1 which is should
already be based on the dig +trace output.
Now check your logs to see if you are still getting odd queries to
destinations that aren't authoritative DNS servers which are being
refused. Use dig +trace to check responses which should match the
http://multirbl.valli.org site responses for that particular RBL or
whitelist excluding IVM which is a subscription-based RBL.
--
David Jones
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> >
> > On 09/18/2017 06:03 PM, Chris wrote:
> [snip]
> >
> > >
> > >
> > > 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, here's my output. I ran as sudo to see all inclusive:
>
> sudo netstat -tunlap | grep ":53"
> [sudo] password for chris:
> tcp 0 0
> 192.168.122.1:53 0.0.0.0:* LISTEN 1245/name
> d
>
> tcp 0 0
> 127.0.1.1:53 0.0.0.0:* LISTEN 1316/dnsm
> as
> q
> tcp 0 0
> 192.168.0.51:53 0.0.0.0:* LISTEN 1245/name
> d
>
> tcp 0 0
> 127.0.0.1:53 0.0.0.0:* LISTEN 1245/name
> d
>
> tcp 0 0
> 192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
>
>
> tcp 1 1
> 192.168.0.51:33475 198.97.190.53:53 CLOSING -
>
>
> tcp 0 0
> 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
>
>
> tcp 0 0
> 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
>
>
> tcp 1 1
> 192.168.0.51:40633 198.97.190.53:53 CLOSING -
>
>
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* 2323/dnsm
> as
> q
> udp 0 0
> 192.168.122.1:53 0.0.0.0:* 1245/name
> d
>
> udp 0 0
> 127.0.1.1:53 0.0.0.0:* 1316/dnsm
> as
> q
> udp 0 0
> 192.168.0.51:53 0.0.0.0:* 1245/name
> d
>
> udp 0 0
> 127.0.0.1:53 0.0.0.0:* 1245/name
> d
>
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* 1533/snap
> we
> b
> udp 0 0
> 0.0.0.0:5353 0.0.0.0:* 1004/avah
> i-
> daemon:
> udp6 0 0
> :::5353 :::* 1533/snap
> we
> b
> udp6 0 0
> :::5353 :::* 1004/avah
> i-
> daemon:
>
I neglected to insert my /etc/bind/named.conf.options file
acl goodclients {
127.0.0.1;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
geoip-directory "/usr/share/GeoIP";
recursion yes;
allow-query { goodclients; };
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow
multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses
replacing
// the all-0's placeholder.
//forwarders {
//127.0.0.1;
//};
//=============================================================
===========
// If BIND logs error messages about the root key being
expired,
// you will need to update your keys. See https://www.isc.org/
bind-keys
//=============================================================
===========
//dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
//listen-on-v6 { any; };
listen-on { any; };
};
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:23:13 up 16:02, 1 user, load average: 1.80, 1.00, 0.68
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> On 09/18/2017 06:03 PM, Chris wrote:
[snip]
> >
> > 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, here's my output. I ran as sudo to see all inclusive:
sudo netstat -tunlap | grep ":53"
[sudo] password for chris:
tcp 0 0
192.168.122.1:53 0.0.0.0:* LISTEN 1245/named
tcp 0 0
127.0.1.1:53 0.0.0.0:* LISTEN 1316/dnsmas
q
tcp 0 0
192.168.0.51:53 0.0.0.0:* LISTEN 1245/named
tcp 0 0
127.0.0.1:53 0.0.0.0:* LISTEN 1245/named
tcp 0 0
192.168.0.51:56697 192.52.178.30:53 TIME_WAIT -
tcp 1 1
192.168.0.51:33475 198.97.190.53:53 CLOSING -
tcp 0 0
192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
tcp 0 0
192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
tcp 0 0
192.168.0.51:56609 192.52.178.30:53 TIME_WAIT -
tcp 0 0
192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
tcp 0 0
192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
tcp 0 0
192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
tcp 0 0
192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
tcp 0 0
192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
tcp 0 0
192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
tcp 1 1
192.168.0.51:40633 198.97.190.53:53 CLOSING -
udp 0 0
192.168.122.1:53 0.0.0.0:* 2323/dnsmas
q
udp 0 0
192.168.122.1:53 0.0.0.0:* 1245/named
udp 0 0
127.0.1.1:53 0.0.0.0:* 1316/dnsmas
q
udp 0 0
192.168.0.51:53 0.0.0.0:* 1245/named
udp 0 0
127.0.0.1:53 0.0.0.0:* 1245/named
udp 0 0
0.0.0.0:5353 0.0.0.0:* 1533/snapwe
b
udp 0 0
0.0.0.0:5353 0.0.0.0:* 1004/avahi-
daemon:
udp6 0 0
:::5353 :::* 1533/snapwe
b
udp6 0 0
:::5353 :::* 1004/avahi-
daemon:
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:12:33 up 15:51, 1 user, load average: 0.36, 0.71, 0.55
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
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
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
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
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
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
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
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
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
11:47:09 up 2:25, 1 user, load average: 0.37, 0.50, 0.54
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
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
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
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.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
11:04:17 up 1:42, 1 user, load average: 0.53, 0.34, 0.38
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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.55
> 43 RCVD_IN_IADB_LISTED 4 4.26 0.00 4.55
> 48 RCVD_IN_IADB_DK 4 4.26 0.00 4.55
> 51 RCVD_IN_IADB_RDNS 3 3.19 0.00 3.41
> 55 RCVD_IN_IADB_SENDERID 3 3.19 0.00 3.41
> 81 RCVD_IN_IADB_OPTIN 1 1.06 0.00 1.14
>
> 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.
Re: ISIPP - Re: bb.barracudacentral.org
Posted by Chris <cp...@embarqmail.com>.
On Mon, 2017-09-18 at 09:28 -0500, David Jones wrote:
> On 09/18/2017 09:12 AM, Kevin A. McGrail wrote:
> >
> > On 9/16/2017 4:36 PM, Chris wrote:
> > >
> > > I'm also seeing issues with ISIPP which is in 20_dnsbl_tests.cf.
> > > I've
> > > attached the message I sent them as well as their reply. Another
> > > issue
> > > I noticed with ISIPP is
> > >
> > > Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
> > > 'ns1.ns.isipp.com/A/IN': 67.227.190.38#53
> > > Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
> > > 'ns2.ns.isipp.com/A/IN': 67.227.190.38#53
> > >
> > > My network is up
> > >
> > > chris@localhost:~$ time host isipp.com
> > > isipp.com has address 67.227.187.192
> > > isipp.com mail is handled by 5 smtp.secureserver.net.
> > > isipp.com mail is handled by 0 concerto.isipp.com.
> > > isipp.com mail is handled by 10 mailstore1.secureserver.net.
> > >
> > > real 0m0.866s
> > > user 0m0.008s
> > > sys 0m0.004s
> > > chris@localhost:~$ time host isipp.com
> > > isipp.com has address 67.227.187.192
> > > isipp.com mail is handled by 0 concerto.isipp.com.
> > > isipp.com mail is handled by 10 mailstore1.secureserver.net.
> > > isipp.com mail is handled by 5 smtp.secureserver.net.
> > >
> > > real 0m0.010s
> > > user 0m0.008s
> > > sys 0m0.000s
> > >
> > > Problem, or something I shouldn't concern myself about?
> > Good question. Perhaps another rate-limit issue or they block
> > dynamic IPs.
> >
> > I took this off-list by accident but Chris has low volume and uses
> > a
> > Dynamic IP. I wonder if ISIPP is similar to barracuda in that it
> > should
> > be considered for removal from the default rules. Anyone have any
> > feedback?
> >
> > regards,
> > KAM
> 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.55
43 RCVD_IN_IADB_LISTED 4 4.26 0.00 4.55
48 RCVD_IN_IADB_DK 4 4.26 0.00 4.55
51 RCVD_IN_IADB_RDNS 3 3.19 0.00 3.41
55 RCVD_IN_IADB_SENDERID 3 3.19 0.00 3.41
81 RCVD_IN_IADB_OPTIN 1 1.06 0.00 1.14
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
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
09:47:45 up 26 min, 1 user, load average: 0.30, 0.44, 0.97
Description: Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic
Re: ISIPP - Re: bb.barracudacentral.org
Posted by David Jones <dj...@ena.com>.
On 09/18/2017 09:12 AM, Kevin A. McGrail wrote:
> On 9/16/2017 4:36 PM, Chris wrote:
>> I'm also seeing issues with ISIPP which is in 20_dnsbl_tests.cf. I've
>> attached the message I sent them as well as their reply. Another issue
>> I noticed with ISIPP is
>>
>> Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
>> 'ns1.ns.isipp.com/A/IN': 67.227.190.38#53
>> Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
>> 'ns2.ns.isipp.com/A/IN': 67.227.190.38#53
>>
>> My network is up
>>
>> chris@localhost:~$ time host isipp.com
>> isipp.com has address 67.227.187.192
>> isipp.com mail is handled by 5 smtp.secureserver.net.
>> isipp.com mail is handled by 0 concerto.isipp.com.
>> isipp.com mail is handled by 10 mailstore1.secureserver.net.
>>
>> real 0m0.866s
>> user 0m0.008s
>> sys 0m0.004s
>> chris@localhost:~$ time host isipp.com
>> isipp.com has address 67.227.187.192
>> isipp.com mail is handled by 0 concerto.isipp.com.
>> isipp.com mail is handled by 10 mailstore1.secureserver.net.
>> isipp.com mail is handled by 5 smtp.secureserver.net.
>>
>> real 0m0.010s
>> user 0m0.008s
>> sys 0m0.000s
>>
>> Problem, or something I shouldn't concern myself about?
>
> Good question. Perhaps another rate-limit issue or they block dynamic IPs.
>
> I took this off-list by accident but Chris has low volume and uses a
> Dynamic IP. I wonder if ISIPP is similar to barracuda in that it should
> be considered for removal from the default rules. Anyone have any feedback?
>
> regards,
> KAM
I am receiving many hits on *_IADB_* rules just fine recently for emails
from constantcontact.com and others.
--
David Jones
Re: ISIPP - Re: bb.barracudacentral.org
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 9/16/2017 4:36 PM, Chris wrote:
> I'm also seeing issues with ISIPP which is in 20_dnsbl_tests.cf. I've
> attached the message I sent them as well as their reply. Another issue
> I noticed with ISIPP is
>
> Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
> 'ns1.ns.isipp.com/A/IN': 67.227.190.38#53
> Sep 16 12:09:38 localhost named[1284]: host unreachable resolving
> 'ns2.ns.isipp.com/A/IN': 67.227.190.38#53
>
> My network is up
>
> chris@localhost:~$ time host isipp.com
> isipp.com has address 67.227.187.192
> isipp.com mail is handled by 5 smtp.secureserver.net.
> isipp.com mail is handled by 0 concerto.isipp.com.
> isipp.com mail is handled by 10 mailstore1.secureserver.net.
>
> real 0m0.866s
> user 0m0.008s
> sys 0m0.004s
> chris@localhost:~$ time host isipp.com
> isipp.com has address 67.227.187.192
> isipp.com mail is handled by 0 concerto.isipp.com.
> isipp.com mail is handled by 10 mailstore1.secureserver.net.
> isipp.com mail is handled by 5 smtp.secureserver.net.
>
> real 0m0.010s
> user 0m0.008s
> sys 0m0.000s
>
> Problem, or something I shouldn't concern myself about?
Good question. Perhaps another rate-limit issue or they block dynamic IPs.
I took this off-list by accident but Chris has low volume and uses a
Dynamic IP. I wonder if ISIPP is similar to barracuda in that it should
be considered for removal from the default rules. Anyone have any feedback?
regards,
KAM