mailing list archives
Re: Open Resolver Dataset Update
From: "A. Pishdadi" <apishdadi () gmail com>
Date: Tue, 9 Apr 2013 15:55:00 -0500
In the last 2 weeks we have seen double the amount of ddos attacks, and way
bigger then normal. All of them being amplification attacks. I think the
media whoring done during the spamhaus debacle motivated more people to
invest time building up there openresolver list, since really no one has
disclosed attacks of that size and gave the blueprints of how to do it. Now
we know the attack has been around for awhile but no one really knew how
big they could take it until a couple weeks ago..
Now I know your openresolver DB is meant to get them closed but it would
take only a small amount of someones day to write a script to crawl your
database.. You go to fixedorbit.com or something of the sort, look up the
as's of the biggest hosting companies, plop there list of ip allocaitons in
to a text file, run the script and boom i now have the biggest open
resolver list to feed my botnet.. Maybe you should require some sort of
CAPTCHA or registration to view that database. While im sure people have
other ways of gathering up the open resolvers , you just took away all the
work and handed it to them on a silver platter. While i am and others
surely are greatful for the data, i think a little more thought should be
put in how you are going to deliver the data to who should have it, and
that would be the network / AS they are hanging off of.
just my 2 cents..
P.S. I would like to get a list for our AS off list if you can reply back
On Tue, Apr 9, 2013 at 3:15 PM, Jared Mauch <jared () puck nether net> wrote:
The main criteria is the RCODE=0 vs RCODE=5 refused.
I exposed the Recursion Available bit this last week to cover more of the
use cases, but many servers provide a very large referral to root.
You are correct in that your system doesn't provide that so should be less
"visible" as a result. I haven't coded everything to pull out that level
of data from the responses.
Of the responding IPs, a fair percentage 89% respond with the RA bit set.
I'm working to close the gap on exposing the direct data of those last 11%
in a more detailed bit of information, including if it provides a root
referral or otherwise.
Hope this helps,
On Apr 9, 2013, at 8:59 AM, Tom Laermans <tom.laermans () phyxia net> wrote:
If you mean there can be a referral with RCODE=0 and Recursion Available
= 0, you'll need a third column actually documenting if there is a
This server is listed in ORP:
$ dig www.google.be @126.96.36.199
; <<>> DiG 9.7.3 <<>> www.google.be @188.8.131.52
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 615
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.google.be. IN A
;; Query time: 6 msec
;; SERVER: 184.108.40.206#53(220.127.116.11)
;; WHEN: Tue Apr 9 14:58:21 2013
;; MSG SIZE rcvd: 31
RCODE=0, Recursion available=0:
Hence my question, what is it doing wrong?
On Mon, 2013-04-08 at 07:05 -0400, Jared Mauch wrote:
The referral, including a referral to root can be quite large. Even
larger than answering a normal query. I have broken the data out for the
purpose of letting people identify the IPs that provide that.
On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans () phyxia net>
As far as I know, responding either NOERROR or REFUSED produces
packets of the same size.