Re: [council] Discussion draft on unique, authoritativeroot
- To: John C Klensin <email@example.com>
- Subject: Re: [council] Discussion draft on unique, authoritativeroot
- From: Brian E Carpenter <firstname.lastname@example.org>
- Date: Tue, 29 May 2001 08:51:26 -0500
- CC: Peter de Blanc <email@example.com>, "M. Stuart Lynn" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Fabio.Bigi@itu.int, email@example.com, firstname.lastname@example.org, "Bridget P. Cosgrave" <Bridget.Cosgrave@etsi.fr>, GerryLawrence_Internet <email@example.com>, Brian Moore_Internet <firstname.lastname@example.org>, email@example.com, Livia Rosu Lunguran <Livia.Rosu@etsi.fr>, PSO-PC <PSO-PC@list.etsi.fr>, Harald Alvestrand <Harald@Alvestrand.no>
- Organization: IBM
- References: <3273985380.991116463@P2>
- Sender: firstname.lastname@example.org
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.
John C Klensin wrote:
> --On Tuesday, 29 May, 2001 05:35 -0400 Peter de Blanc
> <email@example.com> 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').
> 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.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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