Hi Ted, Thanks for your relevant comments, :-)
Ted Lemon <mel...@fugue.com>于2017年8月16日周三 上午1:28写道： > I tried to ignore this thread for a while, but became alarmed after > reading some of the recent comments, so I went and read the document. > > As far as I can tell, this document gives no clear justification for why > it is a good idea. We have not been told of the practical operational > problems that motivate it. It appears to solve a problem we have already > solved, in a way that creates new security vulnerabilities. We have not > been told why the existing solution to the problem is not adequate. > > If the authors have a real problem that they feel has not already been > solved, the first step in the process ought to be to present that > information to the working group, rather than to present a solution to the > working group with no clear statement about the problem it solves, and in > particular no data about the seriousness of the problem. > For what it's worth, which isn't much since the chairs haven't issued a > call for adoption, I don't think the working group should work on this. > 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% Details in: Dealing with temporary domain name issues in the DNS <https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html> <https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html> The operational problem is, subdomain wildcards waste recursive cache capacity. Existing solution to the problem is not adequate in recursive operating environment at present, because of low DNSSEC deployment. > > On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver <v...@rhyolite.com> wrote: > >> ] From: Lanlan Pan <abby...@gmail.com> >> >> ] Give the choice to operators, time is the best witness, like IP >> surpassed >> ] ATM. >> >> That is backwards. IP did not surpass ATM, because IP came long before >> ATM. Instead, end-to-end ATM was the last gasp of the end-to-end >> circuit switching point of view. End-to-end ATM was supposed to replace >> IP, but instead the new virtual circuits of ATM came far too late and >> did not solve the problems that packet switching had already solved. >> >> ATM has not yet died and is still common for some uses. For example, >> ATM is used as x.25 was used under IP in the early days of IP; many >> DSL installations use AMT VCs. >> >> A better and more relevant history is that of the SPF RR. The SPF RR >> was supposed to replace the use of the TXT rtype for SPF. The SPF RR >> was widely available in deployed DNS authoritative servers (via BIND). >> I think it was in milter modules for sendmail and postfix. Nevertheless, >> it died because it came late, was only a modest improvement, and required >> operators to do something more than they were doing. >> >> >> Vernon Schryver v...@rhyolite.com >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
