On 3/31/16 6:18 AM, abby pan wrote: > > > Stephane Bortzmeyer <[email protected] <mailto:[email protected]>>于2016 > 年3月29日周二 下午9:48写道： > > On Mon, Mar 28, 2016 at 05:38:01AM +0000, > abby pan <[email protected] <mailto:[email protected]>> wrote > a message of 246 lines which said: > > > 1) baofeng recursive ddos attack(2009): > > http://www.pcworld.com/article/165319/article.html > > A more technical reference for this attack is the OARC talk > <https://www.dns-oarc.net/files/workshop-200911/Ziqian_Liu.pdf> > > yes, in ziqian_liu's talk , they "Increase the TTL of baofeng.com > <http://baofeng.com> related RRs" on the cache to rescue > > > > 2) baidu dns hijack(2010): > > > > http://www.zdnet.com/article/baidu-dns-records-hijacked-by-iranian-cyber-army/ > > This paper says it was purely social engineering on the registrar. No > change in the DNS would help. > > > if cache can temporary prolong the ttl of baidu ns, that will help.
It actually can't really unless you're proposing that a recursive resolver refuse to honor the ns/soa after ttl expiration. that makes it rather hard to change providers, transfer zones or replace nameservers. which are of course reasons why you would have a lower ttl on such records anyway. if you're suggesting that large content providers zones are sufficiently ossified that they never change or are re/delegated well, that isn't true. > > > The selection is automatic, commonly TOP-N domain names. > > OK, so if I want my own personal vanity domain name to be well cached, > I just have to hire a botnet to send many requests for > bortzmeyer.org <http://bortzmeyer.org>. > > Also, it seems you mix "important" with "often > queried". impots.gouv.fr <http://impots.gouv.fr> (the tax service) > is important in France, if > you cannot reach it, you'll not be able to pay and you wil be > fined. But it does not see a lot of requests, typical people use it > once a year. > > > yes, simply online TOP-N is easy to around. > > But the "hot" domain we can pre-set, as your example, like "*.gov.cn > <http://gov.cn>"， “qq.com <http://qq.com>", "baidu.com > <http://baidu.com>", "taobao.com <http://taobao.com>" in china. > > We manage the "most important" domain list, not just from dns query > count, but also the service data flow associated with the domain, also > from some company alliance. > > > > 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. > > You mean the name server has to know BGP? > > > I mean if cache server can check the NS BGP status with some addtional > module, the rtt of dns query will be benefits. > > But as Evan Hunt says, that's not "should" , but can be a choice. > > > > > 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. > > I did not say pre-fetching is bad, I said it does not require any > change in the DNS server (it can be done from the outside). > > > I did not say that need change in the DNS server's normal task. > > but it can be some additonal module to active when encounter ddos or > hijack ( outside the normal case ) . > > > > > In "baofeng recursive ddos attack": short domain TTL + ns shutdown + > > huge amount client fail and retry prolonging the TTL can partly > > defense the attack. > > I did not say increasing the TTL is bad, I said it is a change in the > protocol and therefore your draft has to declare it updates RFC 1034 > (and 1035). > > > same as above, it can be some additonal module to active when encounter > ddos or hijack ( outside the normal case ) . > > so that's not change in the protocol, not change the normal dns > query/response. > > it's actived to auto defense when huge count to 1s TTL suddenly rise. > > > > > Sometimes recursive receive hijack data (cache-poisoning attack). > > if there is an security analysis module, users will more benefits. > > If it is just asserting the validity of data before returning it to > the user, what do you need besides the already existing RFC 2181 > (section 5.4.1) and RFC 5452 (specially sections 6 and 9)? > > > again, it is not change the protocol, but some additional module to > validate the data in cache dns operation. > > comodo, opendns has give the protect service : > http://www.computerworld.com/article/2872700/6-dns-services-protect-against-malware-and-other-unwanted-content.html > > for example, detect hijack phishing ip of xxx.qq.com <http://xxx.qq.com> > , help to correct or block it. > -- > > Best Regards > > Pan Lanlan > Tel: +86 186 9834 2356 > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
