Thanks Alex. I was just looking for a good contact! Regards, KAM
On January 14, 2018 2:30:36 PM EST, Alex Lasoriti <lasor...@spamteq.com> 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 AAAA >> > 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 AAAA 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
