El 17 ag 2017, a les 0:09, Lanlan Pan <abby...@gmail.com> va escriure: > We can use SWILD to optimize it, not need to detecting, just remove items > which SWILD marked, to save cost.
So, can you talk about how your proposal saves cost over using a heuristic? > 2) cache miss > All of temporary subdomain wildcards will encounter cache miss. > Query xxx.foo.com <http://xxx.foo.com/>, then query yyy.foo.com > <http://yyy.foo.com/>, zzz.foo.com <http://zzz.foo.com/>, ... > We can use SWILD to optimize it, only query xxx.foo.com > <http://xxx.foo.com/> for the first time and get SWILD, avoid to send > yyy/zzz.foo.com <http://zzz.foo.com/> queries to authoritative server. Can you characterize why sending these queries to the authoritative server is a problem? > 3) DDoS risk > The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC > unsigned. > For example, [0-9]+.qzone.qq.com <http://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. Why do you prefer this? Just saying "we prefer ..." is not a reason for the IETF to standardize something. There are a bunch of problems with your proposal, as I'm sure others have remarked before. It breaks DNSSEC validation for stub resolvers that aren't aware of SWILD. In the absence of DNSSEC validation, it creates a new and very effective spoofing attack (poison the cache with bogus SWILD records). Etc. So you need to clearly explain why it is that you prefer this approach, and not just say that it's something you like. Are you using it in production? Do you have data on what it does? Do you have data on the behavior of real-world caches that you can cite that shows that SWILD would produce more of an improvement than just using a better cache aging heuristic?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
