In message <86be15f2-2a2e-42e7-8d0d-51c2dbbd7...@nominum.com>, Ted Lemon writes: > > On Aug 2, 2015, at 9:46 PM, Zhiwei Yan <yanzhi...@cnnic.cn> wrote: > > -DDOS: the current situation is that it is very very easy to construct > > a DNS packet and then the bandwidth requirement to defend DDOS continuely > > increases. the additional cost will be introduced in the "cookies" > > scheme, but it will be more flexible in this case because it will be very > > easy to diffentiate the packets-with-cookies and packets-without-cookies, > > and the cost will be much lower compared with the DNSSEC > > I alluded to this in my response to Donald, but just to expand on it a > bit, this is only possible if the vast majority of the stub resolvers are > doing cookies. Otherwise, responding to a DDoS attack in this way does > exactly what the attacker wants: it disables DNS resolution for your > domain or for your users. So this is not a valid use case for the draft > unless you can explain how sufficient deployment would occur.
Cookie code has zero cost when responding to non cookie requests. Returning BADCOOKIE to all invalid / no server cookie avoids the entire lookup process and rate limiting code. > To illustrate what I am talking about, Google was unwilling to deploy > AAAA records for their servers until the number of hosts that were able > to succeed in connecting with the AAAA records present was >99.7%, if I > remember that presentation correctly. No, Google was unwilling to return AAAA records to all hosts until the number of hosts that weren't taking a multi-second connect penalty dropped to < 0.03%. Google returned AAAA to resolvers with a working IPv6 path with very early. Initially you requested that Google white list your resolvers. > This is a very, very high bar. > If you are under a DDoS attack, of course, you may be willing to settle > for a lower rate of success, but I would expect cookies to hover well > under 50% pretty much forever, because there is no incentive for the host > operating system vendor to implement it in the stub resolver, and look > how long it took to get WinXP numbers down. And thatâs not even taking > into account all the broken middleware out there, e.g. DNS proxies on > home routers. So even if vendors implement it, when will end-users > deploy it? Just recursiver server to authoritative server is reason enough to deploy cookies. Stub to recursive server would be better though for many recursiver servers allow-recursion is enough. > In practice, therefore, in order to deal with DDoS attacks like this, the > server weathering the attack will have to maintain state about clients, > so that it continues to serve clients that donât support cookies. So we > have additional code on the server, the ultimate result of which is that > the server does substantial extra work, not less work, increasing, not > decreasing, the effectiveness of the DDoS attack. No. > Itâs certainly true that if support for cookies were near 100% in > clients, and were not blocked by middleware, we could in fact turn off > stateful heuristics and see a benefit from cookies, but thatâs a really > big if. The incentives are all in the wrong places here. If you are under attack the current method drop or send back TC=1. TC=1 means managing many more TCP session on both the server and client side. With cookies it is drop or BADCOOKIE which keeps the traffic on UDP if there isn't a good server cookie. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
