Subject: [DNSOP] on engineering cost/benefits

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Aug 2017 16:30:36 -0700

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

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 15 Aug 2017 09:27:50 +0000

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-masked]>于2017年8月15日周二 上午7:30写道：

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 10:26:21 -0700

> The complexity is the real world, No Silver Bullet.

the real world is organic: it is what it is, and our job is to discover 
it, and sometimes model it, and sometimes enhance it through automation.

we are not talking about that. we are talking about artifice: what shall 
we build, with what choices, and what projected outcomes?

your dismissal is noted.

-- 
P Vixie