Moin! On 17 Aug 2017, at 0:09, Lanlan Pan wrote: > 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. As you mention me, with the data you supplied it is highly unlikely that a lot of records will still be active in the Cache because of the TTL and how least recently used (LRU) algorithms work.
> 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 That is not what the draft suggest and is not what the current implementations of this or similar features do. They all rely on a cache with a fixed size and if the record that normally would be expired is still in the cache extend it's lifetime when queried. The records you mention are not queried and thus would be expired because other records that are queried more frequently would have overwritten them anyway. There also is nearly no harm if these queries fail in case the authoriative is not responding as most of those queries you describe are computer and not human generated. The draft above and similar techniques where done because of the twitter.com problem. Now I can assure you that twitter.com will always be hot (asked at least every couple of seconds) in a regular resolver at your ISP or a provider of DNS services, and thus the expired record will probably still be in the cache. > 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. The cost of sending a query now and then is very low resolvers do that all the time and the rate on which they have to do that is very low. However to actually save costs you would have to deploy your proposal on the authoritative server that have that behaviour and the resolvers. Good luck with that. I also assume some of the authorities are actually interested in the queries so they would not implement your proposal even if they could, making the theoretical improvement of 0.12% even smaller. > 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. See above. > 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. As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall attacks as others call them are usually asking every subdomain once (and these botnets take great care on doing this) the record would be removed by the least recently used (LRU) algorithm when other records that are used more are questioned. While these attacks on recursive resolvers can stress the recursive to authoritative part of the resolver there are techniques to limit the exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring Workshop in Amsterdam on that topic: https://indico.dns-oarc.net/event/21/contribution/29 and the summary of it is that all major vendors of recursive resolvers handle this, so again while your solution would be one once universally deployed there are already solutions to the problem out there, so why do another one? So long -Ralf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
