[dns-operations] Limiting DNSSEC-based amplification attacks (Was: Weird TXT record
David Conrad
drc at virtualized.org
Fri Jun 24 22:21:26 UTC 2011
On Jun 24, 2011, at 11:20 AM, David Miller wrote:
> Absolutely, typical state tracking would only keep track of the sources of queries that you received. However, good source address randomization on the part of an attacker will make every "attack query" you receive be sourced from a different address.
But that would defeat the amplification attack, no? I'd think an attack with random source addresses would more likely be a DoS against the auth server itself, in which case filling up the state table would trigger a "help, help, I'm being oppressed" trap to the operator who could then take normal DoS mitigation steps.
> Take the max qps that you can accept multiplied by your rate limit period in seconds and that is the number of state entries that you will need to maintain.
Say 1M qps (higher than I think is possible today but I haven't looked at the state of the art in auth servers for a couple of years) and a 1 second rate limit period, that would require a 16MB (worst case) + 1M * ((sizeof pointer) + (size of table entry) + overhead), which given the cost of RAM these days seems feasible to me.
> As a comparison, routers use special fast memory and ASICs to handle the routing of packets for a routing table which for IPv4 is currently ~360,000 prefixes.
That's a teensy bit different since the need for ASICs and TCAMs is driven by the need to deal with 10s of Gbps forwarding speeds. Assuming L root is not an outlier, the total aggregate load on all the root servers combined these days peaks at less than 500,000 qps (L's peak doubled * 13, rounded up).
>> Anyhow, the point is that rate limiting can be helpful in reducing the threat of (some of the) amplification attacks. What's the alternative?
> This is indeed the question. A question to which I don't believe we have a satisfactory answer in current tech - beyond the sledgehammer tactic of "go big, or go home".
I thought the threat being discussed is the use of DNS servers as amplifiers. I don't think "go big or go home" is really applicable to the targets of a DNS amplification attack since it can be anyone on the Internet.
Regards,
-drc
More information about the dns-operations
mailing list