[dns-operations] rate-limiting state(Internet mail)

[samwu(吴洪声)]

in DNSPod, we responded user a random cname like afda7896.dnspod.com to prevent DNS query flood and avoid TCP issue.

Kind regards
--
DNSPod - make your domain intelligent

Sam Wu
Founder & CEO

E-Mail: samwu at dnspod.com
http://www.dnspod.cn
地址: 山东省烟台市开发区长江路28号华新国际大厦1210室 264006
Addr: #1210 HuaXin Intl. Bldg., #28 ChangJiang Rd., Development Dist., YanTai City, ShanDong Prov., China
________________________________
From: Colm MacCárthaigh Colm MacCárthaigh<mailto:colm at stdlib.net>
Date: February 8, 2014 at 1:03:03 AM
To: Tony Finch dot at dotat.at<mailto:dot at dotat.at>
Subject:  Re: [dns-operations] rate-limiting state(Internet mail)
On Fri, Feb 7, 2014 at 6:16 AM, Tony Finch <dot at dotat.at<mailto:dot at dotat.at>> wrote:
What not just the victim? In the absence of RRL the DDoS attack is likely
to cause collateral damage, yes. In the presence of RRL non-victims are
unaffected as long as the attack isn't overwhelming the name server.

Both can cause collateral damage, but to different targets. RRL does reduce the collateral damage to a reflection target. But it also increases the collateral damage to your legitimate users. If an attacker spoofs a popular resolver, then for just 5-10 queries per second they cause a degradation in service to the real legitimate users of that resolver. With the default settings, 12.5% of queries from that resolver may not get any answer at all, even with three attempts, and the lookup time is increased by about 1.3 RTTs on average.  With the resolver trying 3 authoritative nameservers, the availability hit diminishes to about 0.2% (which brings us to two nines), but the RTT hit gets worse.

Now if I have a botnet or client that can generate 1M PPS (this is small, but adjust to any number), I can try to spoof 66,666 popular resolvers (this is a knowable set) at 5 QPS each to 3 auth servers, I can use RRL to degrade service in a more widespread way.

Now, let's say you have the capacity to answer these queries (which is realistic for some) which behavior is better for your users? Just answering the responses? Or rate-limiting the responses?

My overall point is that with RRL there is some trade-off between protecting innocent reflection victims and opening yourself to an attack that degrade service to your real users in some way. Were RRL to be widely deployed, attacks could shift to table-exhaustion and popular-resolver spoofing and be effective in different ways.

--
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140207/334edee1/attachment.html>