You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michelle Sullivan <mi...@sorbs.net> on 2016/01/28 14:54:28 UTC
Re: Turning off queries to SORBS
Very old thread I know, but have been busy elsewhere...
Bill Cole wrote:
>
> The SOA and 13 in-zone NS records for dnsbl.sorbs.net both have 1-day
> TTL's, while the A records for the rbldns$x.sorbs.net names to which
> the NS records point have 10-minute TTL's and the IPs those names
> resolves to do change, although not every 10 minutes. The sorbs.net
> serial is 2015050602, implying that the NS records may have been
> stable for a week but that there were 2 or three different rounds of
> changes on May 6. Currently, 11 of the 13 NS's for the dnsbl zone are
> responding to me, sending back 7 different zone serial numbers between
> them, using epoch timestamps spread across 1:02:32. That's not
> unreasonable considering that the refresh time is 2 hours. There are 2
> pairs of serial numbers ~2 minutes apart, so I would guess that's the
> minimum update frequency. The other 2 (rbldns0 and rbldns1) aren't
> responding at all. Interestingly, the upstream glue NS records (from
> the sorbs.net authority) pointing at the rbldns$x names have 10-minute
> TTLs,
> In effect, that means SORBS can swap IP's for their nameservers in and
> out and get many more than 13 IP's being hit by different portions of
> the net because their nameservers are handing out variant versions of
> the zone and clients are looking for new IPs for the nameservers 144
> times per day.
You pretty much sum it up... However it's not to swap IPs its to allow
us to remove any server that gets DDoSed within a few minutes, similarly
if there is a problem with a particular server... It also allows with
generation of new zone deltas every minute to get all the NS records
cached by the querying servers without resorting to EDNS0 (and therefore
TCP) ... which allow me to scale each server to a minimum of 2500
queries per second all the way up to 40,000 queries per second.
>
> No, it tells you that those specific 4 nameserver addresses didn't
> respond to queries.
4 is a little unusual, but 2 or 3 is not and 1 is certain.. As the DNS
servers reload their zones they stop responding, the servers can reload
their zones every 60 seconds.
> Only the first is currently found in a the collection of authoritative
> nameservers for dnsbl.sorbs.net, but all of them have symmetric PTR/A
> records, implying that they aren't some sort of poisoning artifact.
> Also, the last 3 are in small blocks allocated by SoftLayer to GFI
> Software, the former owner of SORBS.
Where do you see GFI? Nothing should show GFI (all the SL stuff is
owned by Proofpoint)
> Finally, the last 2 are also supposed to be authoritative for
> sorbs.net, and it is possible for the various TTLs' expiration to
> leave one in a position of asking those machines instead of the proper
> authorities.
For information:
sorbs.net NS servers will give glue and authority to a sub selection of
the RBL servers (rbldns[1-17].sorbs.net currently possible)
each zone loaded into the rbldns servers has a random selection of 7 NS
records (random at time of generation with any 'Down' servers not in the
possible list)
> So yes: SORBS has some sort of DNS problem, but it isn't fatal.
>
No, it's probably normal operation, however it would appear to be an
issue when compared to a non-RBL zone.
> The queries to SORBS are *eventually* working, because the normal
> behavior for BIND is to retry with another server when one doesn't
> answer. BIND really wants to tell you about any little problem you'll
> listen too, even if it's transient, so you see these events in logs if
> you log deeply enough.
Some resolvers will send one query to more than one server at the same
time, they then cache the server which responds the fastest as where to
send all future queries until $timeout.
Some send out 3 queries regardless (assuming there are more than 2
servers). (A way to get this to be almost certain behavior is use a
single NS record pointing at multiple A records.)
Some just send out queries to the same servers as they were told about
them, only moving to the next after a lookup failure.
Some servers seem to rotate (round robin) all the NS records in their
caches and will send queries that way.
Some servers randomise the NS servers they will query every time they
make a query.
... The SORBS delegation and RBL servers have their current
setup/design since 2007 because it seems to be the best compromise when
you get DDoSed, and for minimising duplicate data whilst having the
ability to reconfigure your network without *most* people noticing... ;-)
Regards,
--
Michelle Sullivan
http://www.mhix.org/
Re: Turning off queries to SORBS
Posted by Reindl Harald <h....@thelounge.net>.
Am 20.04.2016 um 14:30 schrieb Michelle Sullivan:
>> $ /opt/local/bin/whois 174.36.198.233
>>
>> [... ARIN record elided ...]
>>
>> Found a referral to rwhois.softlayer.com:4321.
>>
>> %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
>> Solutions, Inc. V-1.5.9.6)
>> network:Class-Name:network
>> network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
>> network:Auth-Area:174.36.192.0/18
>> network:Network-Name:SOFTLAYER-174.36.192.0
>> network:IP-Network:174.36.198.232/30
>> network:IP-Network-Block:174.36.198.232-174.36.198.235
>> network:Organization;I:GFI Software
> Hehe... out of date rwhois server... you expect anything else? :P
>
> (GFI were out of the picture 1 Jul 2011...! )
the problem is most likely a /opt/local/bin/whois from the last century
[harry@rh:~]$ whois --version
Version 5.2.12.
[harry@rh:~]$ ls /usr/bin/whois.md
-rwxr-xr-x 1 root root 136K 2016-03-29 15:54 /usr/bin/whois.md
[harry@rh:~]$ /usr/bin/whois 174.36.198.233
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
#
https://whois.arin.net/rest/nets;q=174.36.198.233?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 174.36.0.0 - 174.37.255.255
CIDR: 174.36.0.0/15
NetName: SOFTLAYER-4-7
NetHandle: NET-174-36-0-0-1
Parent: NET174 (NET-174-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS36351
Organization: SoftLayer Technologies Inc. (SOFTL)
RegDate: 2008-09-12
Updated: 2013-07-12
Ref: https://whois.arin.net/rest/net/NET-174-36-0-0-1
OrgName: SoftLayer Technologies Inc.
OrgId: SOFTL
Address: 4849 Alpha Rd.
City: Dallas
StateProv: TX
PostalCode: 75244
Country: US
RegDate: 2005-10-26
Updated: 2013-02-20
Ref: https://whois.arin.net/rest/org/SOFTL
ReferralServer: rwhois://rwhois.softlayer.com:4321
OrgTechHandle: IPADM258-ARIN
OrgTechName: IP Admin
OrgTechPhone: +1-214-442-0601
OrgTechEmail: ipadmin@softlayer.com
OrgTechRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
OrgAbuseHandle: ABUSE1025-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-214-442-0601
OrgAbuseEmail: abuse@softlayer.com
OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE1025-ARIN
RAbuseHandle: ABUSE1025-ARIN
RAbuseName: Abuse
RAbusePhone: +1-214-442-0601
RAbuseEmail: abuse@softlayer.com
RAbuseRef: https://whois.arin.net/rest/poc/ABUSE1025-ARIN
RTechHandle: IPADM258-ARIN
RTechName: IP Admin
RTechPhone: +1-214-442-0601
RTechEmail: ipadmin@softlayer.com
RTechRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
RNOCHandle: IPADM258-ARIN
RNOCName: IP Admin
RNOCPhone: +1-214-442-0601
RNOCEmail: ipadmin@softlayer.com
RNOCRef: https://whois.arin.net/rest/poc/IPADM258-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
Verweis auf rwhois.softlayer.com:4321 gefunden.
%rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
Solutions, Inc. V-1.5.9.6)
network:Auth-Area:174.36.192.0/18
network:Class-Name:network
network:Street-Address:NA
network:City:NA
network:Postal-Code:27
network:Country-Code:SA
network:Tech-Contact;I:sysadmins@softlayer.com
network:Abuse-Contact;I:abuse@softlayer.com
network:Admin-Contact;I:IPADM258-ARIN
network:Created:2008-06-12 16:43:22
network:Updated:2014-01-20 07:00:50
network:Updated-By:ipadmin@softlayer.com
%ok
Re: Turning off queries to SORBS
Posted by Michelle Sullivan <mi...@sorbs.net>.
Bill Cole wrote:
> On 28 Jan 2016, at 8:54, Michelle Sullivan wrote:
>
> [...]
>
>>> Only the first is currently found in a the collection of authoritative
>>> nameservers for dnsbl.sorbs.net, but all of them have symmetric PTR/A
>>> records, implying that they aren't some sort of poisoning artifact.
>>> Also, the last 3 are in small blocks allocated by SoftLayer to GFI
>>> Software, the former owner of SORBS.
>> Where do you see GFI? Nothing should show GFI (all the SL stuff is
>> owned by Proofpoint)
>
> Tell that to SL, e.g.:
>
> $ /opt/local/bin/whois 174.36.198.233
>
> [... ARIN record elided ...]
>
> Found a referral to rwhois.softlayer.com:4321.
>
> %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
> Solutions, Inc. V-1.5.9.6)
> network:Class-Name:network
> network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
> network:Auth-Area:174.36.192.0/18
> network:Network-Name:SOFTLAYER-174.36.192.0
> network:IP-Network:174.36.198.232/30
> network:IP-Network-Block:174.36.198.232-174.36.198.235
> network:Organization;I:GFI Software
Hehe... out of date rwhois server... you expect anything else? :P
(GFI were out of the picture 1 Jul 2011...! )
--
Michelle Sullivan
http://www.mhix.org/
Re: Turning off queries to SORBS
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 28 Jan 2016, at 8:54, Michelle Sullivan wrote:
[...]
>> Only the first is currently found in a the collection of
>> authoritative
>> nameservers for dnsbl.sorbs.net, but all of them have symmetric PTR/A
>> records, implying that they aren't some sort of poisoning artifact.
>> Also, the last 3 are in small blocks allocated by SoftLayer to GFI
>> Software, the former owner of SORBS.
> Where do you see GFI? Nothing should show GFI (all the SL stuff is
> owned by Proofpoint)
Tell that to SL, e.g.:
$ /opt/local/bin/whois 174.36.198.233
[... ARIN record elided ...]
Found a referral to rwhois.softlayer.com:4321.
%rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network
Solutions, Inc. V-1.5.9.6)
network:Class-Name:network
network:ID:NETBLK-SOFTLAYER.174.36.192.0/18
network:Auth-Area:174.36.192.0/18
network:Network-Name:SOFTLAYER-174.36.192.0
network:IP-Network:174.36.198.232/30
network:IP-Network-Block:174.36.198.232-174.36.198.235
network:Organization;I:GFI Software
network:Street-Address:15300 Weston Parkway, Suite 104
network:City:Cary
network:State:NC
network:Postal-Code:27513
network:Country-Code:US
network:Tech-Contact;I:sysadmins@softlayer.com
network:Abuse-Contact;I:abuse@gfi.com
network:Admin-Contact;I:IPADM258-ARIN
network:Created:2010-02-22 10:26:09
network:Updated:2015-04-18 20:06:14
network:Updated-By:ipadmin@softlayer.com
%ok