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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
