The complexity is the real world, No Silver Bullet. It is the fact, there is always more than one way to do it, not only for subdomain wildcard cache, or IPv4/IPv6 migration. Take virtual network tunneling for example, we have VN-Tag, VXLAN, NVGRE, ...
Give the choice to operators, time is the best witness, like IP surpassed ATM. Actually, SWILD can work with DNSSEC, reduce validation cost by avoiding NSEC range calculation. Repeat my option: I believe that DNSSEC deployment is decided by rising the dns security need, not by an additional subdomain wildcard feature. If SWILD will reduce DNSSEC deployment as you say, what about RPZ break DNSSEC validation in the same measure principle ? RPZ seem not to cause DNSSEC to be more ubiquitous. Paul Vixie <[email protected]>于2017年8月15日周二 上午7:30写道： > I realize that for the Perl language, "there is always more than one way > to do it". That was a design choice, and the results are now part of > Perl's reputation as a "swiss-army chainsaw" perfectly suitable for the > creation of unmaintainable programs. > > Generally, we do not provide more than one way to accomplish something, > because it imposes costs on operators and implementers and especially on > QA/test teams, who must support all such methods, for competitive or > coverage reasons. Distributed system complexity is a function of message > types and their options and permutations and combinations, and state > variables and their options and permutations and combinations. More > complexity is almost always going to add more cost than benefit, and > every argument about adding new states, variables, or messages has to > begin with the engineering economics: what are the costs & benefits? > > For example if it's possible to express the nonexistence of a wildcard > in two ways, each publisher of DNS information will have to decide > whether to support only one and if so which one, or both ways. Every > implementer of a DNS client library or a DNS-aware application will also > have to choose. If some choose method A and others choose method B than > the functionality will not be effectively present. If everyone chooses > to support both then there was no advantage to the second way. > > In terms of cost/benefit, someone who wanted to provide a new way to > support signalling of non-wildcard should be comparing the effort of > standardizing, implementing and deploying a second way, vs. pushing for > broader deployment of the existing way. One could either come to the > IETF, and to the authors of PowerDNS, BIND, NSD, Unbound, and companies > like Nominum, Microsoft, and so on, asking "could you please support > this second way to do something your systems already know how to do?", > or one could approach one's own I.T. department and the I.T. departments > of our customers, suppliers, and partners, and say, "could you please > support this existing standard by changing your operational practice to > include DNSSEC signing and validation?" > > In the first case, it's all new work, which adds complexity for all > operators and all implementers, and may have the effect of reducing > DNSSEC deployment if some number of operators cared only about this > feature (which we'll call SWILD) and have no other reason to deploy > DNSSEC. This concern is heightened because the DNSSEC specification is > crap, and there's been unending concern as to whether its costs are > greater than its benefits. DNSSEC rests on knife-edge, ready to fall. > > In the second case, it's mostly just turning stuff on that's already > defined, already implemented, and is an option in virtually all current > generation DNS software. We would not be adding new test cases for > QA/test teams. And importantly, we would be adding new effort to the > task of causing DNSSEC to be more ubiquitous. > > This kind of engineering economics tradeoff should be obvious. I > apologize to anyone who is about to ask me why I appear to be trying to > teach my grandmother how to chew cheese. Consider this a PSA for > newcomers for whom shiny objects are an unalloyed good, and aren't seen > in the context of costs and benefits and effects and side effects. > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
