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: [email protected]
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:[email protected]>
Date: February 8, 2014 at 1:03:03 AM
To: Tony Finch [email protected]<mailto:[email protected]>
Subject:  Re: [dns-operations] rate-limiting state(Internet mail)
On Fri, Feb 7, 2014 at 6:16 AM, Tony Finch 
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to