Open Resolver Problems

Tue Mar 26 14:21:17 UTC 2013

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 at 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. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130326/40964b04/attachment.sig>