On Tue, 26 Mar 2013 08:13:49 -0000, Nick Hilliard said:
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. ;)