Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On 2018-03-20 (04:56 MDT), Uwe Schindler wrote: > > why they not simply blocked the Hetzner recursive name servers instead of > everything I would have to assume bad behavior on Hetzner's part. -- 'And stars don't care what you wish, and magic don't make things better, and no-one doesn't get burned who sticks their hand in a fire.'
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Hi Uwe! On Fr, Mär 16, 2018 at 12:18:10 +0100, Uwe Schindler wrote: Did you solve this problem in the meantime? Unfortunately this also Yes, I was contaced by a key account manager of Spamhaus. I got a free datafeed query service key. Maybe you could contact Spamhaus to tell them about your problems? Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
RE: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Hi, Thanks Stephan, the same happened to me. It is still unclear to me, why they not simply blocked the Hetzner recursive name servers instead of everything. The offered solution is also fine, but bad for other users of their service through SpamAssassin or Postfix, correctly setting everything up using a local (e.g., unbound) recursive DNS server. Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: Stephan Seitz > Sent: Tuesday, March 20, 2018 10:59 AM > To: Uwe Schindler > Cc: users@spamassassin.apache.org; 'Alex Lasoriti' > Subject: Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME > > Hi Uwe! > > On Fr, Mär 16, 2018 at 12:18:10 +0100, Uwe Schindler wrote: > >Did you solve this problem in the meantime? Unfortunately this also > > Yes, I was contaced by a key account manager of Spamhaus. I got a free > datafeed query service key. > > Maybe you could contact Spamhaus to tell them about your problems? > > Shade and sweet water! > > Stephan > > -- > | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
RE: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Hi Stephan, > I see the problems as well in my postfix logs (I’m a Hetzner custom=r as > well): > warning: dnsblog_query: lookup error for DNS query > 36.142.70.194.zen.spamha=s.org: Host or domain name not found. Name > service error for name=36.142=2E70.194.zen.spamhaus.org type=A: Host not > found, try again > > If I trace the DNS traffic I see that there are no DNS responses (IPv4 > and IPv6). Did you solve this problem in the meantime? Unfortunately this also affects my low-email-traffic Hetzner vserver, too. I also use a local DNS (unbound). From what I figured out, any requests to spamhaus servers from any IPv4 or IPv6 address of most Hetzner subnets are ignored. If I do the request from any other IP (outside Hetzner) it works. Nevertheless, this IP blocking issue is a different one than the CNAME issue discussed here. Unfortunately this issue affects one of the servers @Hetzner that Apache Lucene is using to test their builds. The issue started around December 15th, 2017. Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Hi Alex! On So, Jan 14, 2018 at 07:30:36 +, Alex Lasoriti wrote: On 2018-01-14 17:20, Ian Zimmerman wrote: I am getting these, too. With other news in the last few weeks, are things falling apart at spamhaus? Not that I am aware of :) The infrastructure keeps consolidating and things are getting stronger and stronger! What other news are you referring to ? Andreas M. Kirchwitz wrote in de.admin.net-abuse.mail (good old Usenet ;-) (Message-id: ) that some (or most) Hetzner customers couldn’t contact the spamhaus DNS servers anymore. This started in December. I see the problems as well in my postfix logs (I’m a Hetzner customer as well): warning: dnsblog_query: lookup error for DNS query 36.142.70.194.zen.spamhaus.org: Host or domain name not found. Name service error for name=36.142.70.194.zen.spamhaus.org type=A: Host not found, try again If I trace the DNS traffic I see that there are no DNS responses (IPv4 and IPv6). Many greetings, Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On 2018-01-14 19:30, Alex Lasoriti wrote: > > things falling apart at spamhaus? > > Not that I am aware of :) The infrastructure keeps consolidating > and things are getting stronger and stronger! What other news are you > referring to ? I probably had lodged in my memory (what remains of it) the thread on SDLU started by Glenn English mid-last month. Sorry for the conflation/confusion, and thanks for the detailed explanation of the current issue. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On Sun, 2018-01-14 at 19:30 +, Alex Lasoriti wrote: > On 2018-01-14 17:20, Ian Zimmerman wrote: > > > > On 2018-01-14 17:07, Per Jessen wrote: > > > > > > > > AFAIK, bind does not accept NS records with CNAMEs, only A or > > > > > > records. It looks like spamhaus updated their nameserver config > > > and > > > added cloudflare by way of CNAME. > Hi all, > > this was a "sunday experiment" done on only one of our current 20 NS > records, > addressing in total about 75 nameservers. So it affected more of > less 5% of the > lookups (that did not fail, just had to be retried). It's my fault > and you > can blame me personally :) We are now back to the normal setup - the > CNAME > is no longer there and will not come back. Sorry for the extra noise > in > logs; I am quite confident that nothing was really seriously broken, > but I understand that it may have annoyed some people. > Thanks for the explanation Alex, I wasn't annoyed, just baffled. As you said, everything is back to normal. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 15:18:27 up 4 days, 6:06, 1 user, load average: 0.21, 0.25, 0.30 Description:Ubuntu 16.04.3 LTS, kernel 4.13.0-26-generic signature.asc Description: This is a digitally signed message part
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Thanks Alex. I was just looking for a good contact! Regards, KAM On January 14, 2018 2:30:36 PM EST, Alex Lasoriti wrote: >On 2018-01-14 17:20, Ian Zimmerman wrote: >> On 2018-01-14 17:07, Per Jessen wrote: >> >> > AFAIK, bind does not accept NS records with CNAMEs, only A or >> > records. It looks like spamhaus updated their nameserver config >and >> > added cloudflare by way of CNAME. > >Hi all, > >this was a "sunday experiment" done on only one of our current 20 NS >records, >addressing in total about 75 nameservers. So it affected more of less >5% of the >lookups (that did not fail, just had to be retried). It's my fault and >you >can blame me personally :) We are now back to the normal setup - the >CNAME >is no longer there and will not come back. Sorry for the extra noise >in >logs; I am quite confident that nothing was really seriously broken, >but I understand that it may have annoyed some people. > >While I was aware of RFC 2181 (1997), the current wide usage of CNAMEs >in the >context of load balancing and geo-optimization schemes where the CNAME >points to a record of an external unrelated domain, led me to think >that >nowadays things could have been less strict than in the past with >respect >to CNAMEs pointing outside. While a CNAME implies some inefficiencies >due to >the extra lookup, geo-optimization could bring very important >advantages to >the DNSBL ecosystem - such themes did not exist in 1997 when RFC 2181 >was written. >It is now obvious that it continues to be a no-no, but perhaps the time >has >come to relax this restriction. In the meanwhile we'll do it in some >other way. > >The context of this experiment is that we are currently investigating >usage >of a content delivery network such as Cloudflare's to bring DNS data >closer >to users, but still retaining the rbldnsd-based server farm. >The purpose is to decrease the average latencies, but also decrease the >number of extra queries done to get the A or records of >nameservers, >as we would like to decrease the number of NS records drastically, >serving to users only a subset of nameservers close to their location, >or at >least to the location of the resolver sending the query on their >behalf. > >While in principle DNS resolvers should choose the closest >authoritative >server, in practice they still keep trying all the others, and some >resolvers >really choose the authoritative randomly (see the Yu, Larson, Wessels >and Zhang >paper "Authority Server Selection of DNS Caching Resolvers" if you do >not believe >that!). For us this means that we find US-originating queries >constituting >the majority of DNS traffic reaching our mirrors in places like Saudi >Arabia, >Australia, South Africa, places where bandwidth and hosting may be >quite >expensive. And those servers were meant to serve the communities in >those >countries, not to serve US users that are always a few ms away from the >closest >mirror. So we are basically trying to overcome the rather poor ability >of >DNS itself to keep traffic local, and have less bytes flying over the >planet. > >> I am getting these, too. With other news in the last few weeks, are >> things falling apart at spamhaus? > >Not that I am aware of :) The infrastructure keeps consolidating >and things are getting stronger and stronger! What other news are you >referring to ? > >Alex >Spamhaus Technology
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On 2018-01-14 17:20, Ian Zimmerman wrote: > On 2018-01-14 17:07, Per Jessen wrote: > > > AFAIK, bind does not accept NS records with CNAMEs, only A or > > records. It looks like spamhaus updated their nameserver config and > > added cloudflare by way of CNAME. Hi all, this was a "sunday experiment" done on only one of our current 20 NS records, addressing in total about 75 nameservers. So it affected more of less 5% of the lookups (that did not fail, just had to be retried). It's my fault and you can blame me personally :) We are now back to the normal setup - the CNAME is no longer there and will not come back. Sorry for the extra noise in logs; I am quite confident that nothing was really seriously broken, but I understand that it may have annoyed some people. While I was aware of RFC 2181 (1997), the current wide usage of CNAMEs in the context of load balancing and geo-optimization schemes where the CNAME points to a record of an external unrelated domain, led me to think that nowadays things could have been less strict than in the past with respect to CNAMEs pointing outside. While a CNAME implies some inefficiencies due to the extra lookup, geo-optimization could bring very important advantages to the DNSBL ecosystem - such themes did not exist in 1997 when RFC 2181 was written. It is now obvious that it continues to be a no-no, but perhaps the time has come to relax this restriction. In the meanwhile we'll do it in some other way. The context of this experiment is that we are currently investigating usage of a content delivery network such as Cloudflare's to bring DNS data closer to users, but still retaining the rbldnsd-based server farm. The purpose is to decrease the average latencies, but also decrease the number of extra queries done to get the A or records of nameservers, as we would like to decrease the number of NS records drastically, serving to users only a subset of nameservers close to their location, or at least to the location of the resolver sending the query on their behalf. While in principle DNS resolvers should choose the closest authoritative server, in practice they still keep trying all the others, and some resolvers really choose the authoritative randomly (see the Yu, Larson, Wessels and Zhang paper "Authority Server Selection of DNS Caching Resolvers" if you do not believe that!). For us this means that we find US-originating queries constituting the majority of DNS traffic reaching our mirrors in places like Saudi Arabia, Australia, South Africa, places where bandwidth and hosting may be quite expensive. And those servers were meant to serve the communities in those countries, not to serve US users that are always a few ms away from the closest mirror. So we are basically trying to overcome the rather poor ability of DNS itself to keep traffic local, and have less bytes flying over the planet. > I am getting these, too. With other news in the last few weeks, are > things falling apart at spamhaus? Not that I am aware of :) The infrastructure keeps consolidating and things are getting stronger and stronger! What other news are you referring to ? Alex Spamhaus Technology
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On 14 Jan 2018, at 11:07 (-0500), Per Jessen wrote: Chris wrote: I started seeing this yesterday evening - https://pastebin.com/Q01t63uf AFAICT it's happening on every message that is processed by SA. This is: spamassassin -V SpamAssassin version 3.4.1 running on Perl version 5.22.1 Any ideas? AFAIK, bind does not accept NS records with CNAMEs, only A or records. This is not a BIND issue, aside from the (optional) logging of the bad NS record. The specification of DNS (as precisely clarified by https://tools.ietf.org/html/rfc2181#section-10.3) does not allow NS names which are resolved via a CNAME record. Like MX records, NS records often exist in order to jump a resolution path across administrative boundaries, so they are required to point to the primary (i.e. "canonical") name of the target to prevent uncontrolled redirection. It looks like spamhaus updated their nameserver config and added cloudflare by way of CNAME. Which is a rather surprising error. Both organizations should know better. Thankfully, all the other authoritative NS targets have A and/or records. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On 2018-01-14 17:07, Per Jessen wrote: > AFAIK, bind does not accept NS records with CNAMEs, only A or > records. It looks like spamhaus updated their nameserver config and > added cloudflare by way of CNAME. I am getting these, too. With other news in the last few weeks, are things falling apart at spamhaus? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
Chris wrote: > I started seeing this yesterday evening - > https://pastebin.com/Q01t63uf AFAICT it's happening on every message > that is processed by SA. This is: > > spamassassin -V > SpamAssassin version 3.4.1 > running on Perl version 5.22.1 > > Any ideas? AFAIK, bind does not accept NS records with CNAMEs, only A or records. It looks like spamhaus updated their nameserver config and added cloudflare by way of CNAME. Brgds Per -- Per Jessen, Zürich (1.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
On Sun, 2018-01-14 at 09:07 -0600, Chris wrote: > I started seeing this yesterday evening > - https://pastebin.com/Q01t63uf > I saw the same thing in last night's logwatch report and its being reported in today's 'message' log. According to my logs it started here at Jan 13 22:41:03 and is still happening: the last ocurrence was at Jan 14 15:11:04, i.e. 50 minutes ago with the last message I've received. I analysed my logs by running: sudo cat /var/log/messages* | grep 'spamhaus.*CNAME' | sort NOTE 1: it is not getting written to /var/log/maillog or any other logs, only to /var/log/messages Your start/end times will differ somewhat because I'm running a low volume, private mail system. NOTE 2: I'm running Fedora 27. I upgraded all my hosts on Friday 12th and rebooted them all around 22:00 that evening. These messages didn't appear in my logs until almost 24 hours later on Saturday night, so I don't think its related to Friday's system updates. Martin
skipping nameserver '0.ns.spamhaus.org' because it is a CNAME
I started seeing this yesterday evening - https://pastebin.com/Q01t63uf AFAICT it's happening on every message that is processed by SA. This is: spamassassin -V SpamAssassin version 3.4.1 running on Perl version 5.22.1 Any ideas? Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 08:59:26 up 3 days, 23:47, 1 user, load average: 0.43, 0.36, 0.42 Description:Ubuntu 16.04.3 LTS, kernel 4.13.0-26-generic signature.asc Description: This is a digitally signed message part