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

On Thu, Jan 9, 2014 at 6:50 AM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

> --On Tuesday, January 07, 2014 15:58 +0100 Eliot Lear
> <lear(_at_)cisco(_dot_)com> 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.
+1

Some of the constraints on the DNS system are set by existing technology.

But some of the constraints are not and it greatly damages ICANN when I see
the head of ICANN making misleading technical arguments to claim that a
particular outcome is impossible as I saw on Tuesday this week.

When pressed he withdrew his original claim and announced that he has hired
the original architect of DNS to perform a thorough re-evaluation of the
architecture and design asking if things could be done differently.
Presumably because the original architects of Internet services are well
known for their enthusiasm for re-imagining and re-engineering their
deployed legacy designs.


Another variation of the bogus technical argument is 'we can't do X because
it would allow Russia to do Y and increase control.'

It may not be turned on all the time but we know that when it suits them,
Russia simply diverts traffic in Russia for ALL DNS root services to
servers of their own. They used that capability to effect during the
Georgia crisis.


When I was up at Oxford, Lord Marshall came to tell lies about the nuclear
power program. Papers released since during the attempt to privatize
nuclear power show that Marshall knew or should have known that the
technical arguments he was making were untrue.

Due to climate change we might actually need to build new nuclear capacity
but the incontrovertible fact that the UK establishment lied early and lied
often about the safety and economics of the program has created means that
the necessary level of trust is simply not there.


Technical arguments that can only be understood by experts are actually
weak ones.


Oh and one more thing. For years people have tried to ridicule my concern
that US control of ICANN might result in the Cuba or Palestine CC TLD codes
being dropped out of the root zone.

Anyone who has been following US politics this week will know that emails
from the private office of a Governor previously one of the frontrunners
for the 2016 presidential nomination prove beyond doubt that the Governor's
minions shut down part of the busiest bridge in the world for a petty act
of political revenge. While we can't do very much about the risk that a
person of that type would gain control of the NSA we can and should make
sure that the Internet institutions are protected against that type of
politician.

-- 
Website: http://hallambaker.com/