DNS design (was: Re: Split the IANA functions?)

[John C Klensin <[e-mail]>]

--On Tuesday, January 07, 2014 15:58 +0100 Eliot Lear
<[e-mail]> wrote:

> Andrew,
> 
> It's clear that I wasn't clear.  Deciding on a tree structure
> has political implications, be that DNS, RPKI, or other (and
> there are other).  To ignore those implications would be
> unwise.  They are weighed against technical considerations, as
> always.
>...

Eliot,

In the hope of focusing the discussion a bit, I think it would
be more accurate to say that "having a tree structure...r
"having decided on a tree structure...".

It feels a little strange for me to be defending the DNS design
because I've never been a huge fan of some aspects of it, but a
little bit of insight into the context of those decisions may be
helpful.

I was not involved in the DNS design process, but I was doing
work on databases, including distributed databases, at the time
in the early to mid-1980s.  Against the backdrop of the database
state of the art at the time, if one started with design
criteria of approximately:

-- replacing the name-to-address and
	name-to-limited-supplementary-information functions of
	the Host Table without significant loss of functionality
-- having a hierarchical name structure (which does not,
	itself, imply a hierarchical database)
-- having something that could be administratively
	distributed at multiple levels of the name structure
-- having a distributed database that could be plausibly
	implemented without lock-commit-acknowledge or
	journal-based update facilities
-- having an arrangement that would facilitate local
	caching, not just for performance but as a mechanism to
	allow systems that were temporarily disconnected from
	all or part of the network to keep functioning reasonably
-- The result needed to be plausible for non-specialists
	to implement in a way that would interoperable.
	
Most of the above are documented in the various pre-DNS papers.
Most are also pretty obvious.  Given how bad some
implementations have been, there is a pretty good case to be
made that the design failed on the last criterion, but a
non-hierarchical alternative, especially given the then state of
the art, would have been much worse in that regard.

There just were not a lot of choices other than a hierarchical
database system.  The designers could have made some different
choices within the general hierarchical model, some of which I
hinted about in my earlier note.  I don't know if those
alternatives were even considered (and suspect most of them were
not).   But the decision to use a hierarchical model, again
given the state of the art, had to be pretty much determined by
those  design criteria.

I think a choice between something that meets the criteria and
is comparatively simple, robust, understandable, and
implementable and something that is much more complex and/or
that lacks robustness against network interruptions is an
engineering choice (and an obvious one).  One could argue that
it is political, but that requires arguing either that every
decision the involves either implementation or operational
economics or other operational issues is political.  

One could also argue that the criteria were wrong and that "no
central administrative or coordination function" should have
been a requirement.  But that requirement would be a very
difficult one technically even today and the environment at the
time -- IANA existed well before the DNS and was generally
trusted and the DNS design was a lot less centralized than its
predecessor-- just didn't call for it.  So, except with extremes
of hindsight about what we might like to have had today given an
evolution path that certainly could not have been accurately
anticipated at the time, I think it is hard to argue that the
omission of a "no central..." criterion was political at the
time.

Of course, one can say today that the technical/ engineering
decisions made then have political implications today but, given
the right set of conditions, that could be true of almost any
decision or fact, as the history of ignorant legislative efforts
to change PI or modify the speed of light amply illustrate.   It
doesn't retroactively make the decisions themselves political as
others have implied.

Finally, with regard to CLASSes just being treated as a another
level of the hiararchy, a sort of super-root... Again, I wasn't
there, no only not there for the DNS design effort but not
involved in the Chaosnet and Hesiod implementations that have
been the major examples of actually deployed and actively used
examples of CLASSes.  But it is clear to me from both reading
the specs and what little I know of those implementations that
kre is correct and the capability is badly underspecified.  I
think there are even some errors in what the spec does appear to
say.  But getting from there to either "there is a political
problem because CLASSes don't work" in the presence of
counterexamples to "don't work" or  "CLASSes just create another
level of the tree with the same properties in all CLASSes that
the CLASS=IN [sub]tree has" seems to me to be a huge stretch
that is not really justified by either implementation history or
the spec.

Just my opinion, of course.

best,
    john