Re: [council] Discussion draft on unique, authoritativeroot

[Brian E Carpenter <brian@hursley.ibm.com>]

I seem to have joined this conversation half way through, but
as John hints there is some very basic mathematics/computer science
here that no amount of heuristics can change:

  A hierarchical naming structure without a uniquely rooted tree
  is ambiguous (*) and therefore will balkanize the network. 

This is nothing to do with any specific details of the design or
implementation of the DNS. It's simply a mathematical fact, and
as a friend once said to me, you can't vote on facts.

(*) For pedants or obfuscators, this of course should read "potentially
ambiguous" but we know that in the real world, a potentially ambiguous
namespace will in practice become ambiguous.

The earliest work I'm aware of on this topic was done by Charles Dodgson
(a.k.a. Lewis Carroll) although a more conventional source would be any
computer science text on data structures.

   Brian


John C Klensin wrote:
> 
> --On Tuesday, 29 May, 2001 05:35 -0400 Peter de Blanc
> <pdeblanc@usvi.net> wrote:
> 
> > Just one comment, Stuart-  where you say:
> >
> > "These groups then seek to persuade ISPs and Internet users to
> > replace the pre-stored IP addresses of the standard root
> > nameservers with those of their alternative servers."
> >
> > They do not "replace", they "add to" (in this case, the 'hints
> > file').
> 
> Peter,
> 
> I think you are confusing the initial list of root servers (the
> "hints file") with the _content_ of the root zone.  If one adds
> servers to the "hints" list, and some are inconsistent with the
> others, which domains the user will "see" becomes a
> probabilistic matter, especially since the server chosen (more
> or less at random) will immediately cause the "hints" list to be
> replaced by its idea of the authoritative list of servers.
> 
> In case this isn't clear, suppose my "hints" contain the
> existing list of root servers plus additional ones, say "X" and
> "Y".  And assume that the root zone file supported by "X"
> contains delegation records for an "XXX" TLD with NS records
> pointing to NS1.XXX-X.org and NS2.XXX-X.org  and that the one
> supported by "Y" contains delegation records for an "XXX" TLD
> with NS records pointing to NS1.XXX-Y.org and NS2.XXX-Y.org
> (note that the situation with different zones claiming to be a
> top level XXX domain already exists -- this is not a made-up
> example).  The other name servers listed in this augmented hints
> file do not contain delegations for "XXX".
> 
> Now the user's software makes a more or less arbitrary choice
> about which root server to contact out of those listed in the
> hints file.  If it accesses any of the well-known servers, names
> in the XXX domain will not resolve (note that there is no
> looking back and trying a different root server -- that requires
> significant resolver changes and raises other issues associated
> with "DNS searching").  If it accesses the proported "X" root
> server, XXX will resolve, but only that version of XXX
> understood by "X" and its designated servers.  And, if it
> accesses the proported "Y" root server, XXX will resolve, but
> only that version of XXX understood by "Y" and its designated
> servers.  That, of course, implies that "hotteens.XXX" might
> point to two entirely different domains depending on which
> server is chosen by accident, bringing with it all of the other
> problems of multiple, uncoordinated domains.
> 
> RFC2826 really means what it says.  To summarize in simple
> English:  Anything other than a single, unique, authoritative,
> root will inevitably fragment the Internet and result in user
> confusion.   Names that can be resolved by one user will not be
> resolvable by others or, worse, will be resolved to point to
> different sites or subtrees.
> 
> regards,
>     john

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org