Hi, Ted, Yes, as you said, during this stage and the near future, the default support of "cookies" must be low. Then the server will be "tired" to serve both "with-cookies clients" and "without-cookies clients". But I personally do not agree that the "cookies" will burden the server more seriously. Look at DNSSEC, it costs more, but it was adopted because we have requirements on it. Also on "cookies", it is better to find its advantages and use it in the right place. For example, if the bind or some other softwares chould set "cookies" as a optional configuration: do not use it in the normal case, and open it under attack. I mean it's better to use it when necessary as a light-weight guard for the DDoS attack. BR, Zhiwei
发件人： Ted Lemon 发送时间： 2015-08-04 11:12:11 收件人： Zhiwei Yan 抄送： dnsop; Paul Hoffman 主题： Re: [DNSOP] Seeking more WG Last Call reviewfordraft-ietf-dnsop-cookies 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. 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. 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? 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. 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
