Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:
Now explain how you find a recursive nameserver that isn't listed in an NS
entry and *hasn't* been publicized someplace that Google can find it.
The same way you find open mail relays, SSH hosts with weak
user/password combos, bad WordPress installs, etc. - scan for them. If
it is open to the Internet, it will be found (or probably already has
been).
Or you could just get an off-site system (cloud VM), get the software from http://monkey.org/~provos/dnsscan/, and find all your own open recursive DNS servers.
There are different levels of openness for recursive DNS servers though. It looks like Jared's project lists any DNS server that responds with anything other than refused as open. A DNS server could have open recursion "disabled", but still respond with referrals to the root-servers. Older versions of bind seem to do this when configured with allow-recursion for a limited range of IPs. While not really "open" such servers are still useful for DNS amplification. The example config at
http://www.team-cymru.org/Services/Resolvers/instructions.html
for a bind 9.x caching server can be adapted for older bind versions doing caching+authoratative such that it'll provide recursion to those who should have it, and authority for zones for which it needs to do so.
Then wait for a while while it churns through the ~224*2^24 packets it
needs to scan the entire ipv4 internet. Of course, you could write your
own code, but that would take at least 1/2 an hour.
Then you have every open resolver on the internet.
No you don't. You have every open resolver on a very small legacy portion of
the Internet address space that's likely to solve itself in less time than the
open mail relay problem took to solve. I know for a fact there's open resolvers
on the IPv6 side of the fence. Good luck scanning for those. 
And yes, the miscreants *will* get a list of the IPv6 ones, because unlike
whitehat researchers, they won't have a problem with finding a botnet or
two, and asking every bot on the nets "What ASN are you in, and what DNS
server address did DHCP hand you?"
> (Otherwise read as "we'll be glad to fix it if somebody has a brilliant
> idea on how to do so without generating more calls to the help desk than
> the near-zero rate we currently get about DNS amplification issues"....)The whole point of this thread is that dns amplification hurts other
people, not the resolver which is being abused. Just like in the old days,
abusing open mail relays hurt other people more than the relay operator.
Yes, and in those days, a lot of sites said "sure, we'll fix it if somebody
has a good cheat sheet of how to close our relay *without breaking our own
users*". (And yes, I was around in "the old days", and I remember just how
hard it was for some sites to fix the problem).
The problem is that for the open mail relay problem, you could usually
scan your mailserver logs or watch the network traffic for the tell-tale
'MAIL FROM:<fred.q.random@mydomain.com>' and then you'd have a pretty
good idea that you needed to get in touch with Fred and have him fix
his machine to whatever new regime you decided to use to close your
open relay, whether it was SMTP AUTH or 'mail after POP3 AUTH' or whatever.
Figuring out which user sent a DNS packet from off-campus is a bit more
difficult, as the DNS transaction usually doesn't contain any userid info
And if you get a recursive lookup for www.ebay.com from a hotel network,
you don't have a lot of other traffic you can try to correlate. Up
until a few months ago, we *could* have cross-correlated the DNS traffic
to POP3 checks from the same IP address - but that doesn't work as well
since we outsourced almost all our mail to Google. 
Correct.
So when the excuse-me-but-fuck are we going to get serious, and apply
the IDP to any edge carrier who doesn't implement 38?
Cheers,
-- jra
Sure. But OpenDNS, Google, and the other providers of recursive servers
for edge cases can't do that anymore?
Cheers,
-- jra
I wish people would stop bring that up.
I guarantee I see at least as many reflection attack as anyone out there. I have not _once_ called/emailed Open, Google, Dyn, Ultra, or any other professional DNS provider asking them to stop amplifying attacks to us.
If you can run a server as competently as they can, then no one will complain.
For the other 99.99999999% of you, LOCK THAT SHIT DOWN.
Of cos they can. But they take the security of their open recursive servers
very seriously. 99.99999% of the open recursors dont, hence the problem.
amen, brother!
I was throwing up the 'quick & dirty' data that I had for everyone to get access to quickly.
There are a large number of attacks using these servers in the past week. I hope everyone takes a minute and gets with their unix/systems/DNS team and determines what they can do to minimize this.
One other important item:
Stop your customers from being able to spoof! If you punch in 8.8.8.8 (for example) into the system, you will see a number of devices where if a packet is directed at it that respond with 8.8.8.8, either by spoofing, or by forwarding that request to google and spoofing the origin IP.
Same for the 73.73.73.73 IP as well. Those CPE devices should be locked down.
- Jared
Well,
And why not targeting all that animosity to the peers allowing
source IP spoofing?
DNS Servers don't attack you, people letting their customers spoof
source IP do.
And what, *exactly* do they do different from the other 5-9's?
So far, I've seen lots of people say "close that shit down", but only 2
actual URLs posted that basically both say "only do recursion for IP addresses
within your ASN". That's at least a *bit* more helpful than just telling us
to close it down. Unfortunately, we already know now to do that - but that
isn't the problem that some of us are looking to solve, which is "queries from
your own users mobile devices that are currently *outside* your ASN".
(And *please* make note that although the fine networking staff of AS1312
can probably figure this out on our own once we're supplied with a big
enough pile of square tuits and a belt sander, there's a *lot* of AS's out
there that are going to need a tad more hand-holding...)
+1
I don't view this as an either-or situation. One needs both.
- Jared
And why not targeting all that animosity to the peers allowing
source IP spoofing?
I do - and I gave a bunch of talks in europistan over the last 12 months
which included explicit encouragement, practice and configuration for
implementing BCP38 as part of real-time black hole system deployment.
DNS Servers don't attack you, people letting their customers spoof
source IP do.
DNS amp packets attack me. Please stop them from leaving your network, and
I will both implement BCP38 and encourage others to do so. Thank you.
Nick
Let me rephrase the question… How do you find an open IPv6 recursive name server
that isn't listed in an NS entry and hasn't been publicized someplace that Google can
find it?
Owen
That question was already answered ... ask the bots what their resolving name servers are, then check to see if they are open. As IPv6 deployment increases, the answers will increasingly include IPv6 open resolvers.
Doug
Pwn authorative server catering moderately popular domain and share query
sources as torrent file.
In a message written on Tue, Mar 26, 2013 at 06:40:38PM +0200, Saku Ytti wrote:
Pwn authorative server catering moderately popular domain and share query
sources as torrent file.
Run authortative server hosting command and control for a botnet,
log query sources and use for your own purposes.
IPv6 Temporary / Privacy addresses and making your DNS server query from
them outbound might be a useful trick.
This problem made more sense to me ten years ago than it does now.
What mobile devices do you support that don't acquire a suitable local DNS resolver using DHCP or PPP?
Honest question. I presume you wouldn't bring it up if it wasn't a real problem.
Joe