[dns-operations] Limiting DNSSEC-based amplification attacks (Was: Weird TXT record

David Miller dmiller at tiggee.com
Fri Jun 24 23:37:16 UTC 2011

On 6/24/2011 6:21 PM, David Conrad wrote:
> 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.
Yes, you snipped part of my original reply which was:

"With DNS you must keep in mind that queries are UDP which is trivially 
easy to spoof.  Granted, for amplification attacks, the same source is 
used for all queries (otherwise they can't direct the traffic at the 
target).  However, for rate based attacks against DNS itself, with IPv4 
you could see up to ~3 billion possible "valid" (but not really) source 
addresses... with IPv6... forgetaboutit...  The same mechanisms must 
protect DNS servers against both simultaneously."

The key point being that the same mechanisms must protect against both 

>> 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.

This will give you 2 million state table transactions per second (1 
million new states and 1 million states removed in housecleaning) given 
the worst case.  This is not an insignificant number.

>> 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).

For attack mitigation, build to the theoretical maximums or you will be 
disappointed in the results.

>>> 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.

We will have to agree to disagree.  In my opinion, if your amplification 
protection causes you to fall flat under a randomly sources rate based 
attack, then you have failed.


More information about the dns-operations mailing list