4 ms·
A bit disappointed that the truncate bit wasn't mentioned. So, for the open resolver owners playing along at home: Instead of dropping suspect requests send the
by donavanm 14y ago
A bit disappointed that the truncate bit wasn't mentioned. So, for the open resolver owners playing along at home:
Instead of dropping suspect requests send the truncate bit back. There's no byte amplification in the response, which defeats the attacks raison d'etre.
By dropping the incoming packets you're punishing well behaved resolvers. They're going to take a 2-500ms latency hit before retrying another resolver or over tcp. A well behaved resolver will respond to a truncate by sending the same query over tcp. That's only a latency hit of the rtt.
The tcp connection also effectively authenticates control of that source ip address. Now add that src ip to your whitelist of known good resolvers.
Attacker mitigated, other customers not impacted.
- gridspy 14y agoBear in mind that none of these DNS queries are ever sent out of CloudFlare's network - as mentioned in the previous blog entry, none of these incoming responses are valid. See http://blog.cloudflare.com/65gbps-ddos-no-problem http://blog.cloudflare.com/65gbps-ddos-no-problem " What's great is that we can safely respond and ask them to block all DNS requests originating from our network since our IPs should never originate a DNS request to a resolver. "
- donavanm 14y agoPlease to be rereading my comment. It's addressed to anyone running a resolver/authoritative name server, not the attack target. I promise I'm well acquainted with spoofed DNS attacks.