Re: skipping nameserver '0.ns.spamhaus.org' because it is a CNAME

[@lbutlr]

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

[Stephan Seitz]

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

[Uwe Schindler]

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 <stse+spamassas...@fsing.rootsland.net>
> Sent: Tuesday, March 20, 2018 10:59 AM
> To: Uwe Schindler <uschind...@apache.org>
> Cc: users@spamassassin.apache.org; 'Alex Lasoriti' <lasor...@spamteq.com>
> 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

[Uwe Schindler]

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

[Stephan Seitz]

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

[Ian Zimmerman]

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

[Chris]

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

[Kevin A. McGrail]

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

[Alex Lasoriti]

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

[Bill Cole]

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

[Ian Zimmerman]

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

[Per Jessen]

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

[Martin Gregorie]

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