Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU & TTL works fine. SWILD not save many online cache size, because of the queries rate. And Temporary Domain Names/ All Names: 41.7% for 7 days statistics, the rate can be about 10% for 1 day statistics. Because temporary domain names expire after TTL time. Ralf has similar curious.
The problem is: 1) cache size Recursives commonly cache "all queried domain in n days" for some SERVFAIL/TIMEOUT condition, which has been documented in https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01 The subdomain wildcards cache are needlessly, we can use heuristics algorithm for deciding what to cache, or just use simple rule like "select domain which queies time > 5 in last n days". We can use SWILD to optimize it, not need to detecting, just remove items which SWILD marked, to save cost. 2) cache miss All of temporary subdomain wildcards will encounter cache miss. Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... We can use SWILD to optimize it, only query xxx.foo.com for the first time and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative server. 3) DDoS risk The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC unsigned. For example, [0-9]+.qzone.qq.com is a popular SNS website in China, like facebook. If botnets send "popular website wildcards" to recursive, the cache size of recursive will rise, recursive can not just simply remove them like some other random label attack. We prefer recursive directly return the IP of subdomain wildcards, and not rise recursive cach, not send repeat query to authoritative. Ted Lemon <mel...@fugue.com>于2017年8月16日周三 下午8:54写道： > El 16 ag 2017, a les 0:19, Lanlan Pan <abby...@gmail.com> va escriure: > > We analyzed our recursive query log, about 18.6 billion queries from > 12/01/2015 to 12/07/2015. > > We found about 4.7 Million temporary domains occupy the recursive's cache, > which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, > 360safedns, Cloudfront, Greencompute... > > Temporary Domain Names/ All Names: 41.7% > Queries for Temporary Domain Names/ All Queries: 0.12% > > > Okay. So it sounds like you have an algorithm for detecting temporary > domain names. It seems to me that a quicker solution to your problem is > to publish an operational document describing that algorithm and proposing > ways that recursive caches can use it to prune such domains from the cache > early. > > I'm curious if you studied the behavior of existing recursive caches in > the presence of these domains: do they in fact cache at the rate you > predict they will? The reason I ask is that I know that my own company's > cache, which is widely deployed in the exact scenario you are describing, > has a pretty sophisticated set of heuristics for deciding what to cache. > It would surprise me if it exhibited the behavior you are concerned about. > > BTW, your paper is behind a paywall, so please don't cite it as a reason > to do anything in the IETF. If you want the IETF to take action based on > what is in the paper, you need to publish it openly. > > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
