Re[2]: relays.osirusoft.com

returning 127.0.0.2 for everything would be an ugly way to bow out.

yes, but it's been done before.

Someone has been in contact with Joe via phone and posted
to another mailing list That Zhall Not Be Named that
exactly that is happening. The zone is dead, he's put
*.*.*.* in, he's asking people not to use it anymore.
It may be back in the future with a new network setup,
but right now consider it down.

We're working on getting him to send out a public announcement.

Yes, this is due to a massive DDOS. At least three
of the spamfilter BLs have been so attacked this week.

Some of the networks represented here have not been
as timely about helping the BL providers with the
DDOSes as they could be. Please keep in mind that
without dynamic BLs anti-spam folks will fall back
to sending out static block maps, which getting your
IP space out of will be difficult if not impossible.

IT IS VERY MUCH IN NETWORK OPERATORS
BEST INTEREST THAT THIS NOT HAPPEN.

Please take what measures are necessary to help
ensure that your customers are not intentionally
or neglegently DDOSing the BLs.

-george william herbert
gherbert@retro.com

George William Herbert wrote:

Yes, this is due to a massive DDOS. At least three
of the spamfilter BLs have been so attacked this week.

Some of the networks represented here have not been
as timely about helping the BL providers with the
DDOSes as they could be. Please keep in mind that
without dynamic BLs anti-spam folks will fall back
to sending out static block maps, which getting your
IP space out of will be difficult if not impossible.

IT IS VERY MUCH IN NETWORK OPERATORS
BEST INTEREST THAT THIS NOT HAPPEN.

Please take what measures are necessary to help
ensure that your customers are not intentionally
or neglegently DDOSing the BLs.

Well said George,

I have been one of the recepients of the DDoS attacks. If people see non DNS UDP traffic or non Type 3 ICMP traffic aimed at 203.15.51.32/27 it is likely DDoS traffic. Currently I still have at least one IP in that range Null Routed by upstreams.

SORBS may have to implement a subscription model soon to fund more hosts around the world if the DDoS's continue, I am desperately trying to avoid it, should it become nessessary it will be for the +50k queries/day users out there. The point is SORBS is funded soley by myself and through hosting dontations - I have 5 public secondaries donated currently, and I cannot afford, personally, any DDoS proofing other than that I have now. I know of at least 3 other DNSbls that are experiencing DDoS issues, and one DNSbl operator that is scared stiff of DDoS.

Yours

Mat

Note: If anyone wants to talk about SORBS, public secondaries, donations, policy etc... this is not the forum, please contact me off list.

Hello:

If you and others are experiencing DDOS attacks it would be a good idea to
get the affected IP's on to the various lists associated with the tracking
of such events. If you would like me to post them, I would be happy to do
so. Please let me know the IP blocks, other than the one mentioned above,
and I will post them to the lists.

Thanks,

Mike

ok so this part does not mystify me...

Someone has been in contact with Joe via phone and posted
to another mailing list That Zhall Not Be Named that
exactly that is happening. The zone is dead, ...

...because running blackhole lists is surprisingly more hard
than most people think. (witness the sorbs.net message here
a few hours ago complaining of 50Kpkt/day query loads.) i've
paid some dues in this area, so i feel qualified to say that
"i told you so" on this topic. but at least there's no mystery.

this part, on the other hand...

                                              he's put
*.*.*.* in, he's asking people not to use it anymore.

...mystifies me. anyone who has read rfc1034 or rfc1035, even
if they did not also read rfc2181 or rfc2136 or rfc2308, knows
that in a zone containing the following wildcardish data:

  $ORIGIN example.vix.com.
  * 1H IN A 127.0.0.1
  *.* 1H IN A 127.0.0.2
  *.*.* 1H IN A 127.0.0.3
  *.*.*.* 1H IN A 127.0.0.4

the result will be that only the top one will match:

  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16926
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
  ;; QUERY SECTION:
  ;; 40.30.20.10.example.vix.com, type = A, class = IN

  ;; ANSWER SECTION:
  40.30.20.10.example.vix.com. 1H IN A 127.0.0.1

and that in a zone containing only this data:

  $ORIGIN example.vix.com.
  *.*.*.* 1H IN A 127.0.0.4

the result will be that none of them ever match:

  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44811
        ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
  ;; QUERY SECTION:
  ;; 40.30.20.10.example.vix.com, type = A, class = IN

you don't even need to read draft-ietf-dnsext-wcard-clarify-01.txt to know
that putting "*.*.*.*" into a zone won't actually mean, or do, *anything*.

It may be back in the future with a new network setup,
but right now consider it down.

i'm not completely sure, but i don't think this list will see much action
in the future from the sysadmins who had to make emergency config changes
today to avoid bouncing all their e-mail. "once burned, twice shy," eh?
when i deprecated the old $foo.maps.vix.com zones in favour of the their
corresponding replacements $bar.mail-abuse.org some years ago, i had the
foresight to ensure that no mail would be blocked by people who failed to
put in the configuration change. now you can all see why that was nec'y.

...because running blackhole lists is surprisingly more hard
than most people think. (witness the sorbs.net message here
a few hours ago complaining of 50Kpkt/day query loads.) i've

Matt wasn't complaining about query loads. And 50Kpkt/day in queries is
nothing anyway. He was complaining about being DDoS'd by spammers or
others who just don't like dnsbls. AFAIK, SORBS, SPEWS, and Osirusoft
have all been the targets of DDoS's for a few weeks.

this part, on the other hand...

> he's put
> *.*.*.* in, he's asking people not to use it anymore.

...mystifies me. anyone who has read rfc1034 or rfc1035, even
if they did not also read rfc2181 or rfc2136 or rfc2308, knows
that in a zone containing the following wildcardish data:

  $ORIGIN example.vix.com.
  * 1H IN A 127.0.0.1
  *.* 1H IN A 127.0.0.2

This was just a misunderstanding on the part of the previous poster.
Unless he has a copy of the zone (not likely given the unreliability of
Joe's DNS servers lately), he wouldn't be able to see this. I think he
just wasn't familiar with how wildcards worked and assumed each * only
matched one [^.]*, which is incorrect. AFAICT, what he did add was:

* 24H A 127.0.0.2
  24H TXT "Please stop using relays.osirusoft.com"

which is much worse than just emptying the zone, removing it from the
NS's, or shutting down the DNS servers.

when i deprecated the old $foo.maps.vix.com zones in favour of the their
corresponding replacements $bar.mail-abuse.org some years ago, i had the
foresight to ensure that no mail would be blocked by people who failed to
put in the configuration change. now you can all see why that was nec'y.

Mail would only have been blocked if you had done something crazy like the
above.

Mail was delayed (and servers put under heavy load waiting for DNS queries
to time out) when MAPS finally shut off free access without warning (a
week or more after they originally had warned they'd do it, but gave
everyone an extension when there was massive public outcry and they were
unable to keep up with inquiries about buying access).

Ok this time with the correct from address :wink:

Paul Vixie wrote:

ok so this part does not mystify me...

Someone has been in contact with Joe via phone and posted
to another mailing list That Zhall Not Be Named that
exactly that is happening. The zone is dead, ...
   
...because running blackhole lists is surprisingly more hard
than most people think. (witness the sorbs.net message here
a few hours ago complaining of 50Kpkt/day query loads.) i've
paid some dues in this area, so i feel qualified to say that
"i told you so" on this topic. but at least there's no mystery.

I'm not worried about the 50k queries a day, the previous mail was about
setting this a threshold as a 'ok you're saving some money/bandwidth by
using us, help us extend the service and protect against DDoS by paying
a nominal subscription'

I can handle around 6000 DNS queries per second here, but the DDoS hit
the servers with 300,000 packets per second of invalid DDoS crap that I
can't handle alone.

I have been talking to a lot of people about solutions and came up with
a 'distributed DNS blocklist' idea, this led to my post earlier as Joe
had issues with DDoS on the addresses he had listed in the root
nameservers - which I figure is the weakest link all round...

Someone has suggested 'anycasting' what do people (particually you Paul)
think of using anycasting for a DNSbl? (- AS112 anyone?) I think it may
work well... however I am a novice in terms of BGP... As far as I can
tell it involves getting a portable address block (somone suggested
anything less than a /24 would get filtered) and announcing it in
various locations around the Net with local servers behind each of those
announcements.... is this fundamentally correct?

Assuming I am right in my current understanding, I am about to start
looking at the proceedure to get an ASN and then I'll be looking for
some portable IP space if the consensus and thoughts are this will
work. I am thinking along the lines of talking with the other large
DNSbls (particually Easynet (wirehub) and DSBL) about setting up a set
of combined DNSbl servers all anycast'd. This after all will bring an
DDoS machines to the attention of the local networks they are attacking
.... :wink:

Thoughts, comments, flames...?

Thanks for all the offers of support and help, I will get back to
everyone in detail as soon as I get chance.

Yours

Mat

I wouldn't recommend this. If you have two DNS servers on different addresses, everyone can talk to #2 if #1 doesn't answer. If you anycast them, everyone only gets to talk to one, and if that one has problems, too bad, nothing to be done about that except wait until someone fixes the problem or changes the BGP announcement. Also, the built-in DNS RTT load balancing is much more sophisticated than BGP shortest path selection.

I also have serious doubts about the wisdom of having the root servers anycast for similar reasons but in this case the only alternative is not increasing the number of servers as it's impossible to list the new servers under an IP address of their own.

If the number of requests on your servers is the problem and not bandwidth, you could install filters that only allow requests for known users of the service. This means the attackers must first guess and then spoof an address belonging to a registered user, which should take much of the fun out of it. This sounds like a lot of work but you'd have to do something like it anyway when you want to become a paid service.

Point of clarification - In early to mid July, we gave notice we were
securing the zones at the end of July. Starting August 1 we used
"deny" ACLs based on the IP addresses making the largest number of
queries - and we emailed domain contacts for those. The "deny" ACL
was not changed to an "allow" ACL until October 1 - over 10 weeks
after we announced the zones would close. That is hardly "without
warning", nor was it because of public outcry. (The part about not
being able to keep up with inquiries was definitely true, but I did
learn that sleep is highly overrated <g>.)

At no time did we return positive answers for IP addresses that were
not listed. Two years after the fact, we *still* get tens of
thousands of queries a day from IP addresses that are not subscribed.

I noticed that many Windoze mail servers don't bother to check the second
server if the primary's dead.

--vadim