[dns-operations] does anybody know why yahoo+akamai are doing this?
Paul Vixie
paul at vix.com
Thu Mar 23 20:07:57 UTC 2006
# >reflection is enough. doesn't have to be amplified to be painful. the fact
# >that it's from udp/53 will mean it gets through some victim rate limiters
# >where an icmp reply (or other non-amplified reflective attacks) would not.
#
# Can't the originator of the attack source the packets on 53?
of course. they have to, or the reflected responses will never get anywhere
near a hardened victim. but if you're getting a million REFUSEDs per second
from 50K open recursive nameservers, it's hard for your ISP's rate limiter to
dip far enough into the packets to drop the REFUSEDs and pass the queries. in
fact it's hard to drop the responses and only pass the queries. whereas with
other reflective attacks such as those based on TCP or ICMP, it's easy for the
ISP to drop them far far away from the critical infrastructure nameserver that
we are, in this thought experiment, trying to harden.
did you forget that there were three roles in this society? first you've got
the non-BCP38 network and malevolent users of incompetent hosts, who source
streams of queries appearing to come from the victim. last, you've got the
victim, who would like to remain on-net and in-service even though they're
connections from their peers and ISP's are full of reflected responses to
questions they never asked. in the middle, you've got open recursive name
servers who can't tell that the source addresses are spoofed (since they're
in the wrong part of the topology to be able to repudiate such things), and
who therefore need to (a) not send fat responses to queries to thin queries
from off-LAN (or at most off-campus or off-ISP) sources, and (b) not send a
REFUSED response to every single query they're refusing to answer.
i'm feeling way over quota but ed's asking good questions. if anybody here
thinks i'm loving the sound of my own voice too much today (or any day) plz
tell me 1x1 and i'll STFU.
More information about the dns-operations
mailing list