Response from ISIPP (was Re: ISIPP - Re: bb.barracudacentral.org)
Hi Guys! This thread was only just brought to our attention, and the thread is now several levels deep and a bit old, so if you can help me out with letting me know what the outstanding issues are, I'd really appreciate it. As best as I can tell from reading through the thread online, there are two questions: 1. Something to do with our zones not responding (?) and 2. Something which is causing questions regarding the IADB rules, however I can't find what triggered it or the actual question. We did have an issue with our master zone server a few weeks ago, however to the best of my knowledge it was a) resolved quickly, and b) hasn't happened again. We also have several secondaries on line so, at least in theory, any lookups to the IADB should have been serviced as usual. Are folks still seeing issues with that? As for #2, I'm here to answer any questions and to address any concerns you may have. We treasure (seriously) our relationship with SA - we developed the IADB response codes with Craig Hughes *specifically* so that SA could take advantage of them, and the IADB generally, so if there are issues now, we definitely want to know and get them addressed. I should also remind folks, in case institutional memory from back then is no longer here, that we are happy to create any new data response code that would be useful for SA. (For example, the "127.3.100.100The only email which comes from this IP address is mailing list email, and that mailing list email is entirely confirmed (double) opt-in" data response code was created at the request of another spam filtering/reporting system, and they make a point of looking for it in our zones now.) As you may know, we consider our first duty to be to the *receiving* community (for those who don't know, I came to this by way of being in-house counsel for Paul Vixie and MAPS, so I am seriously anti-spam, and part of the receiving community); but we can't address any issues if they aren't brought to our attention. That just happened, and here I am! :-) Anne Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy (ISIPP) Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant Legal Counsel: The CyberGreen Institute Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop On 2017-09-18 08:12, "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> >
Re: ISIPP - Re: bb.barracudacentral.org
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 I apologize profusely for this... we (fairly) recently switched our colo and while everything was running as it should have been when we set up, it wasn't until Chris contacted us directly that we were aware that this issue had raised its head. To the best of my knowledge this has been fixed - *please* let me know if it has not (or, indeed, if anyone ever has any other problems, or even just questions!) To address another question, we do not distinguish between queries from static versus dynamic IPs in terms of who can query our zones. As for whether the ISIPP rules should remain in the default ruleset: When we first designed our service - which despite that senders are our customers, was created *for receivers* (remember that I came from MAPS - we *love* taking down spammers), we took great pains to ensure that our data response codes in our zones were easy for SA to use - in fact Craig Hughes and I sat down together and architected it specifically with SA in mind. I knew that our design would be copied (and indeed it was by the other email sender certification company) and we didn't really care that it would be copied, because it meant more spam being able to be caught, with fewer false positives, which, at the end of the day, is what everybody (other than spammers) wants. Obviously I think it would be a shame if a system that was specifically designed with SA in mind was no longer included in the default SA rules; if there is tweaking that needs to be done - new codes created, or heck, even a new SA-specific zone created, we'd be more than happy to do that - that's *always* been how we do things - whatever makes it easiest for the *receiving* community, with whom, at the end of the day, our allegiance lays. ;-) Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy (ISIPP) Legal Counsel: The CyberGreen Institute Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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"; # all
Re: ISIPP - Re: bb.barracudacentral.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
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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
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
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. signature.asc Description: OpenPGP digital signature
Re: ISIPP - Re: bb.barracudacentral.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
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 - pubip0.6 28thibran- snappy-debug 0.31.4-snapd2.26.9 70canonical - snapweb 0.26-11-dev 307 canonical - speed-test 1.8.0 16bartaz - wallpaperdownloader 2.8 16egarcia- -- 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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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
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
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. signature.asc Description: OpenPGP digital signature
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
On 19 Sep 2017, at 16:40, Chris wrote: > Here's the output now of the dig +trace > tcp0 0 > 127.0.0.1:530.0.0.0:* LISTEN - > > tcp0 0 > 127.0.1.1:530.0.0.0:* LISTEN - > > udp0 0 > 127.0.0.1:530.0.0.0:* - > > udp0 0 > 192.168.122.1:530.0.0.0:* - > > udp0 0 > 127.0.1.1:530.0.0.0:* - > > udp0 0 > 0.0.0.0:53530.0.0.0:* - > > udp0 0 > 0.0.0.0:53530.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]: [1505852393.3238] nameserver > '192.168.0.1' > NetworkManager[24113]: [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... signature.asc Description: OpenPGP digital signature
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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
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 " > > > > > tcp0 0 127.0.0.1:530.0.0.0:* > > > > > LISTEN 24019/pdns_recursor > > > > > udp0 0 127.0.0.1:530.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: > > > > tcp0 0 > > > > 192.168.122.1:530.0.0.0:* LISTEN 124 > > > > 5/ > > > > name > > > > d > > > > > > > > tcp0 0 > > > > 127.0.1.1:530.0.0.0:* LISTEN 131 > > > > 6/ > > > > dnsm > > > > as > > > > q > > > > tcp0 0 > > > > 192.168.0.51:53 0.0.0.0:* LISTEN 124 > > > > 5/ > > > > name > > > > d > > > > > > > > tcp0 0 > > > > 127.0.0.1:530.0.0.0:* LISTEN 124 > > > > 5/ > > > > name > > > > d > > > > > > > > tcp0 0 > > > > 192.168.0.51:56697 192.52.178.30:53TIME_WAIT - > > > > > > > > > > > > tcp1 1 > > > > 192.168.0.51:33475 198.97.190.53:53CLOSING - > > > > > > > > > > > > tcp0 0 > > > > 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT - > > > > > > > > > > > > tcp0 0 > > > > 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT - > > > > > > > > > > > > tcp0 0 > > > > 192.168.0.51:56609 192.52.178.30:53TIME_WAIT - > > > > > > > > > > > > tcp0 0 > > > > 192.168.0.51:36143 199.19.56.1:53 TIM
Re: ISIPP - Re: bb.barracudacentral.org
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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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]: [1505852393.3238] nameserver > > '192.168.0.1' > > NetworkManager[24113]: [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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.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]: [1505852393.3238] nameserver > '192.168.0.1' > NetworkManager[24113]: [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
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 " > > > > tcp0 0 127.0.0.1:530.0.0.0:* > > > > LISTEN 24019/pdns_recursor > > > > udp0 0 127.0.0.1:530.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: > > > tcp0 0 > > > 192.168.122.1:530.0.0.0:* LISTEN 1245/ > > > name > > > d > > > > > > tcp0 0 > > > 127.0.1.1:530.0.0.0:* LISTEN 1316/ > > > dnsm > > > as > > > q > > > tcp0 0 > > > 192.168.0.51:53 0.0.0.0:* LISTEN 1245/ > > > name > > > d > > > > > > tcp0 0 > > > 127.0.0.1:530.0.0.0:* LISTEN 1245/ > > > name > > > d > > > > > > tcp0 0 > > > 192.168.0.51:56697 192.52.178.30:53TIME_WAIT - > > > > > > > > > tcp1 1 > > > 192.168.0.51:33475 198.97.190.53:53CLOSING - > > > > > > > > > tcp0 0 > > > 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:56609 192.52.178.30:53TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT - > > > > > > > > > tcp0 0 > > > 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT - > > > > > > > > > tcp0
Re: ISIPP - Re: bb.barracudacentral.org
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 "
tcp0 0 127.0.0.1:530.0.0.0:*
LISTEN 24019/pdns_recursor
udp0 0 127.0.0.1:530.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:
tcp0 0
192.168.122.1:530.0.0.0:* LISTEN 1245/name
d
tcp0 0
127.0.1.1:530.0.0.0:* LISTEN 1316/dnsm
as
q
tcp0 0
192.168.0.51:53 0.0.0.0:* LISTEN 1245/name
d
tcp0 0
127.0.0.1:530.0.0.0:* LISTEN 1245/name
d
tcp0 0
192.168.0.51:56697 192.52.178.30:53TIME_WAIT -
tcp1 1
192.168.0.51:33475 198.97.190.53:53CLOSING -
tcp0 0
192.168.0.51:52483 192.5.6.30:53 TIME_WAIT -
tcp0 0
192.168.0.51:57335 192.5.6.30:53 TIME_WAIT -
tcp0 0
192.168.0.51:56609 192.52.178.30:53TIME_WAIT -
tcp0 0
192.168.0.51:36143 199.19.56.1:53 TIME_WAIT -
tcp0 0
192.168.0.51:47629 199.7.83.42:53 TIME_WAIT -
tcp0 0
192.168.0.51:58201 192.48.79.30:53 TIME_WAIT -
tcp0 0
192.168.0.51:53145 199.19.56.1:53 TIME_WAIT -
tcp0 0
192.168.0.51:55073 199.7.83.42:53 TIME_WAIT -
tcp0 0
192.168.0.51:41719 192.48.79.30:53 TIME_WAIT -
tcp1 1
192.168.0.51:40633 198.97.190.53:53CLOSING -
udp0 0
192.168.122.1:530.0.0.0:* 2323/dnsm
as
q
udp0 0
192.168.122.1:530.0.0.0:* 1245/name
d
udp0 0
127.0.1.1:530.0.0.0:* 1316/dnsm
as
q
udp0 0
192.168.0.51:53 0.0.0.0:* 1245/name
d
udp0 0
127.0.0.1:530.0.0.0:* 1245/name
d
udp0 0
0.0.0.0:53530.0.0.0:* 1533/snap
we
b
udp0 0
0.0.0.0:53530.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
Re: ISIPP - Re: bb.barracudacentral.org
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 " tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 24019/pdns_recursor udp0 0 127.0.0.1:530.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: tcp0 0 192.168.122.1:530.0.0.0:* LISTEN 1245/named tcp0 0 127.0.1.1:530.0.0.0:* LISTEN 1316/dnsmas q tcp0 0 192.168.0.51:53 0.0.0.0:* LISTEN 1245/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1245/named tcp0 0 192.168.0.51:56697 192.52.178.30:53TIME_WAIT - tcp1 1 192.168.0.51:33475 198.97.190.53:53CLOSING - tcp0 0 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT - tcp0 0 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT - tcp0 0 192.168.0.51:56609 192.52.178.30:53TIME_WAIT - tcp0 0 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT - tcp0 0 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT - tcp0 0 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT - tcp0 0 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT - tcp0 0 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT - tcp0 0 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT - tcp1 1 192.168.0.51:40633 198.97.190.53:53CLOSING - udp0 0 192.168.122.1:530.0.0.0:* 2323/dnsmas q udp0 0 192.168.122.1:530.0.0.0:* 1245/named udp0 0 127.0.1.1:530.0.0.0:* 1316/dnsmas q udp0 0 192.168.0.51:53 0.0.0.0:* 1245/named udp0 0 127.0.0.1:530.0.0.0:* 1245/named udp0 0 0.0.0.0:53530.0.0.0:* 1533/snapwe b udp0 0 0.0.0.0:53530.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 extern
Re: ISIPP - Re: bb.barracudacentral.org
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 " > > tcp0 0 127.0.0.1:530.0.0.0:* > > LISTEN 24019/pdns_recursor > > udp0 0 127.0.0.1:530.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: > tcp0 0 > 192.168.122.1:530.0.0.0:* LISTEN 1245/name > d > > tcp0 0 > 127.0.1.1:530.0.0.0:* LISTEN 1316/dnsm > as > q > tcp0 0 > 192.168.0.51:53 0.0.0.0:* LISTEN 1245/name > d > > tcp0 0 > 127.0.0.1:530.0.0.0:* LISTEN 1245/name > d > > tcp0 0 > 192.168.0.51:56697 192.52.178.30:53TIME_WAIT - > > > tcp1 1 > 192.168.0.51:33475 198.97.190.53:53CLOSING - > > > tcp0 0 > 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:56609 192.52.178.30:53TIME_WAIT - > > > tcp0 0 > 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT - > > > tcp0 0 > 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT - > > > tcp1 1 > 192.168.0.51:40633 198.97.190.53:53CLOSING - > > > udp0 0 > 192.168.122.1:530.0.0.0:* 2323/dnsm > as > q > udp0 0 > 192.168.122.1:530.0.0.0:* 1245/name > d > > udp0 0 > 127.0.1.1:530.0.0.0:* 1316/dnsm > as > q > udp0 0 > 192.168.0.51:53 0.0.0.0:* 1245/name > d > > udp0 0 > 127.0.0.1:530.0.0.0:* 1245/name > d > > udp
Re: ISIPP - Re: bb.barracudacentral.org
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 " > tcp0 0 127.0.0.1:530.0.0.0:* > LISTEN 24019/pdns_recursor > udp0 0 127.0.0.1:530.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: tcp0 0 192.168.122.1:530.0.0.0:* LISTEN 1245/named tcp0 0 127.0.1.1:530.0.0.0:* LISTEN 1316/dnsmas q tcp0 0 192.168.0.51:53 0.0.0.0:* LISTEN 1245/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1245/named tcp0 0 192.168.0.51:56697 192.52.178.30:53TIME_WAIT - tcp1 1 192.168.0.51:33475 198.97.190.53:53CLOSING - tcp0 0 192.168.0.51:52483 192.5.6.30:53 TIME_WAIT - tcp0 0 192.168.0.51:57335 192.5.6.30:53 TIME_WAIT - tcp0 0 192.168.0.51:56609 192.52.178.30:53TIME_WAIT - tcp0 0 192.168.0.51:36143 199.19.56.1:53 TIME_WAIT - tcp0 0 192.168.0.51:47629 199.7.83.42:53 TIME_WAIT - tcp0 0 192.168.0.51:58201 192.48.79.30:53 TIME_WAIT - tcp0 0 192.168.0.51:53145 199.19.56.1:53 TIME_WAIT - tcp0 0 192.168.0.51:55073 199.7.83.42:53 TIME_WAIT - tcp0 0 192.168.0.51:41719 192.48.79.30:53 TIME_WAIT - tcp1 1 192.168.0.51:40633 198.97.190.53:53CLOSING - udp0 0 192.168.122.1:530.0.0.0:* 2323/dnsmas q udp0 0 192.168.122.1:530.0.0.0:* 1245/named udp0 0 127.0.1.1:530.0.0.0:* 1316/dnsmas q udp0 0 192.168.0.51:53 0.0.0.0:* 1245/named udp0 0 127.0.0.1:530.0.0.0:* 1245/named udp0 0 0.0.0.0:53530.0.0.0:* 1533/snapwe b udp0 0 0.0.0.0:53530.0.0.0:* 1004/avahi- daemon: udp6 0 0 :::5353 :::*1533/snapwe b udp6 0 0 :::5353 :::*1004/avahi- daemon: Chris -- Chris KeyID 0xE
Re: ISIPP - Re: bb.barracudacentral.org
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 RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM 40RCVD_IN_IADB_SPF4 4.260.0 0 4.5 5 43RCVD_IN_IADB_LISTED 4 4.260.0 0 4.5 5 48RCVD_IN_IADB_DK 4 4.260.0 0 4.5 5 51RCVD_IN_IADB_RDNS 3 3.190.0 0 3.4 1 55RCVD_IN_IADB_SENDERID 3 3.190.0 0 3.4 1 81RCVD_IN_IADB_OPTIN 1 1.060.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.
Re: ISIPP - Re: bb.barracudacentral.org
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 > > > > > > RANKRULE NAME COUNT %OFMAIL > > > > > > %OFSPAM %OFHAM > > > > > > 40RCVD_IN_IADB_SPF4 4.260.0 > > > > > > 0 > > > > > > 4.5 > > > > > > 5 > > > > > > 43RCVD_IN_IADB_LISTED 4 4.260.0 > > > > > > 0 > > > > > > 4.5 > > > > > > 5 > > > > > > 48RCVD_IN_IADB_DK 4 4.260.0 > > > > > > 0 > > > > > > 4.5 > > > > > > 5 > > > > > > 51RCVD_IN_IADB_RDNS 3 3.190.0 > > > > > > 0 > > > > > > 3.4 > > > > > > 1 > > > > > > 55RCVD_IN_IADB_SENDERID 3 3.190.0 > > > > > > 0 > > > > > > 3.4 > > > > > > 1 > > > > > > 81RCVD_IN_IADB_OPTIN 1 1.060.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.20
Re: ISIPP - Re: bb.barracudacentral.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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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 RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM 40RCVD_IN_IADB_SPF4 4.260.00 4.5 5 43RCVD_IN_IADB_LISTED 4 4.260.00 4.5 5 48RCVD_IN_IADB_DK 4 4.260.00 4.5 5 51RCVD_IN_IADB_RDNS 3 3.190.00 3.4 1 55RCVD_IN_IADB_SENDERID 3 3.190.00 3.4 1 81RCVD_IN_IADB_OPTIN 1 1.060.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
Re: ISIPP - Re: bb.barracudacentral.org
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!) signature.asc Description: OpenPGP digital signature
Re: ISIPP - Re: bb.barracudacentral.org
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 > > > > RANKRULE NAME COUNT %OFMAIL > > > > %OFSPAM %OFHAM > > > > 40RCVD_IN_IADB_SPF4 4.260.00 > > > > 4.5 > > > > 5 > > > > 43RCVD_IN_IADB_LISTED 4 4.260.00 > > > > 4.5 > > > > 5 > > > > 48RCVD_IN_IADB_DK 4 4.260.00 > > > > 4.5 > > > > 5 > > > > 51RCVD_IN_IADB_RDNS 3 3.190.00 > > > > 3.4 > > > > 1 > > > > 55RCVD_IN_IADB_SENDERID 3 3.190.00 > > > > 3.4 > > > > 1 > > > > 81RCVD_IN_IADB_OPTIN 1 1.060.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
Re: ISIPP - Re: bb.barracudacentral.org
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 RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM 40RCVD_IN_IADB_SPF4 4.260.004.5 5 43RCVD_IN_IADB_LISTED 4 4.260.004.5 5 48RCVD_IN_IADB_DK 4 4.260.004.5 5 51RCVD_IN_IADB_RDNS 3 3.190.003.4 1 55RCVD_IN_IADB_SENDERID 3 3.190.003.4 1 81RCVD_IN_IADB_OPTIN 1 1.060.001.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
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 > > RANKRULE NAME COUNT %OFMAIL > > %OFSPAM %OFHAM > > 40RCVD_IN_IADB_SPF4 4.260.004.5 > > 5 > > 43RCVD_IN_IADB_LISTED 4 4.260.004.5 > > 5 > > 48RCVD_IN_IADB_DK 4 4.260.004.5 > > 5 > > 51RCVD_IN_IADB_RDNS 3 3.190.003.4 > > 1 > > 55RCVD_IN_IADB_SENDERID 3 3.190.003.4 > > 1 > > 81RCVD_IN_IADB_OPTIN 1 1.060.001.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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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 > RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM > 40RCVD_IN_IADB_SPF4 4.260.004.55 > 43RCVD_IN_IADB_LISTED 4 4.260.004.55 > 48RCVD_IN_IADB_DK 4 4.260.004.55 > 51RCVD_IN_IADB_RDNS 3 3.190.003.41 > 55RCVD_IN_IADB_SENDERID 3 3.190.003.41 > 81RCVD_IN_IADB_OPTIN 1 1.060.001.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. signature.asc Description: OpenPGP digital signature
Re: ISIPP - Re: bb.barracudacentral.org
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 RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM 40RCVD_IN_IADB_SPF4 4.260.004.55 43RCVD_IN_IADB_LISTED 4 4.260.004.55 48RCVD_IN_IADB_DK 4 4.260.004.55 51RCVD_IN_IADB_RDNS 3 3.190.003.41 55RCVD_IN_IADB_SENDERID 3 3.190.003.41 81RCVD_IN_IADB_OPTIN 1 1.060.001.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 signature.asc Description: This is a digitally signed message part
Re: ISIPP - Re: bb.barracudacentral.org
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
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
