Thanks a lot for Stephane's comments, we will give more explanations in next version, :-)
Some backgroud information as follows: Stephane Bortzmeyer <bortzme...@nic.fr>于2016年3月25日周五 下午10:44写道： > > I've read it, noticed that it is not just a documentation of local > practices but it wants to be published as BCP, and: > > * it is not clear which problem it is trying to solve. > > We are trying to give some recommendations on DNS cache service practice, make some operation risk plan which can help to deal with DNS security issues, make better effort to improve internet stability. For example: 1) baofeng recursive ddos attack(2009): http://www.pcworld.com/article/165319/article.html 2) baidu dns hijack(2010): http://www.zdnet.com/article/baidu-dns-records-hijacked-by-iranian-cyber-army/ 3) CN tld ddos attack(2013): http://www.computerworld.com/article/2484097/internet/major-ddos-attacks--cn-domain--disrupts-internet-in-china.html > * the whole idea of a "backup", long-term cache (section 3) is > questionable and I do not find a rationale for it. > When Root/TLD suffering DDoS attack, recursive can use "backup cache" for some rescue. > > * it seems to recommend (section 4) that there is some manual > selection of domains that must be cached (instead of the fully > automatic system of the typical current cache), and, again, there is > no rationale and no discussion. > The selection is automatic, commonly TOP-N domain names. The selected TOP-N domain names are different based on respective online service log and scale. discussion : https://www.ietf.org/archive/id/draft-wang-dnsop-cachesurvey-00.txt > * caching SERVFAIL, as recommended (section 4), raises an interesting > question: for how long? (Unlike NXDOMAIN, SERVFAIL answers do not > provide an indirect TTL) > > How long will the SERVFAIL cache last usually depend on ISP network bgp status, especially when recursive send dns query when the ns server is in other ISP. For example, Old J-Root appears to still receive “legitimate” queries 13 years after it was removed from root hints. ( https://indico.dns-oarc.net/event/24/session/10/contribution/10/material/slides/0.pdf) Similarly, some SERVFAIL will last more than 1 month. * if someone really wants to do "pre-fetching" (section 5), it does > not require a new RFC or an update of the name servers. Just request > the names you want, through the resolver/cache. > > The pre-fetching is something like link-fetching( https://en.wikipedia.org/wiki/Link_prefetching ), shortten the response time. Again, pre-fetching is part of "backup cache" for ddos attack resuce or baidu hijack rescue, etc. > * prolonging the TTL (section 5) is a violation of the RFC > protocol. Or a change but, in that case, it is no longer a BCP > document, it updates RFC 1034 and 1035. > > In "baofeng recursive ddos attack": short domain TTL + ns shutdown + huge amount client fail and retry prolonging the TTL can partly defense the attack. * the selection of the order of answers by "RTT detection" (section > 6)deserves more detail. RTT of what? ICMP echos to the address in > the data part? > > That is Name server selection. something like http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.dns.bind/2010-09/msg00071.html > * the recomandation to filter data before returning it to the client > (section 7) is a violation of infrastructure neutrality and > certainly cannot be recommended without more explanations. > > Sometimes recursive receive hijack data (cache-poisoning attack). if there is an security analysis module, users will more benefits. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Best Regards Pan Lanlan Tel: +86 186 9834 2356
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
