Hi, Ralf, We understand your worries and these negative effects can be fixed or descended in the next version. But anyway, let's go back to the scenario considered by our draft to illustrate its necessity. I show an example as following (although I think we have described it several times. :-)): In order to visit the www.baidu.com, the user has to query www.baidu.com and many other related domain names (for many related resources such as images, java script, html, flash, video, sound), then a series of queries happen as the attached figure shows.
Thank you. Zhiwei Yan At 2016-07-20 20:20:45, "Ralf Weber" <d...@fl1ger.de> wrote: >Moin! > >On 20 Jul 2016, at 7:34, 延志伟 wrote: >> I understand your points, but these risks always be there because DNS >> response is larger than the request, like DNSSEC. >Yes, which is why we have several proposals on how to mitigate the >problem by e.g not giving back ALL qtypes to an ANY question, or rate >limit any or answers in general. There also are tools out there that can >limit based on the answer size, all of that to mitigate or make the >handling of the amplification better. > >> How to avoid DNS DDoS is anther problem. >If you introduce something that makes the answer bigger without >acknowledging that there could be a problem with it or it is another >problem you have not been following what is going on in the Internet >lately. > >Others have acknowledged that and described a way forward to mitigate it >(TCP,TLS,Cookies) which introduce a whole other set of problems (some >introduce additional round trips) which further more diminishes the gain >to effort ratio IMHO. > >> Anyway, the cache should get the data fist and then it can cache them. >> :-) >That is true, but an answer out of the cache is served a lot of times >before it has to be cached again, so you are gaining something for that >tiny fraction of users where the cache is cold or has become cold (not a >problem if you use software that prefetches), but putting all others to >risk. Not a good idea IMHO. > >So long >-Ralf
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
