Re: [DNS] Re: Multiple Roots THREAD CONCLUSION

Re: [DNS] Re: Multiple Roots THREAD CONCLUSION

From: Saliya Wimalaratne <saliya§hinet.net.au>
Date: Thu, 6 Dec 2001 14:36:40 +1100 (EST)
On Thu, 6 Dec 2001, Patrick Corliss wrote:

> Hi Saliya
> 
> To keep David Keegal sweet, this is my last "alt root" post for now.

Hi Patrick,

And no offence to David, but this needs to go to the list (and be
archived).

> On Wed, 5 Dec 2001 09:22:35 +1100 (EST), Saliya Wimalaratne wrote:
> > On Wed, 5 Dec 2001, Patrick Corliss wrote:
> 
> <snip>
> 
> > A DNS name that
> > potentially points to multiple disparate entities depending on which
> > nameserver you query is (from a business perspective) a liability.
> 
> Not necessarily.  Not if it promotes diversity, choice and competition.  I
> mean any competition is a nuisance to those being challenged.

? Of course necessarily. A worked example:

Business 'Foo' licences/leases/buys 'foo.bar' domain and sets up
resolution for 'www.foo.bar' pointing at their website.

Business 'Foobar' licences/leases/buys 'foo.bar' from a different
alternate root, and sets up resolution for 'www.foo.bar' pointing at
*their* website.

Both sites see 'www.foo.bar' as their own. Clients of 'foo' or 'foobar',
depending on which nameserver that they are pointed at, will see one or
the other (or neither!) of the sites.

This is a situation where dependent on the nameserver queried, you can get
multiple disparate entities for a given name 'www.foo.bar'. This is a
liability to *both businesses* (Foo, and Foobar) because of the time and
money that it will take to resolve this. If this were simply not possible
(i.e. there was no alternate root) it would be better for both of them.

> Sorry, but we need to eliminate business perspectives from the argument.
> It's like Beta and VHS.  One might be technically better but it's a tough
> world out there.

? A large part of the whole alternate root argument is business-driven !
('but the consumers *want* .sex') If there were no business perspective,
the argument would not exist to a large degree. Which is it to be ?
Consider the business perspective, or not ? You can't have it both ways.

> > > If that happened, I would guess that the French government would set up a
> > > root server within hours.  And instruct all of the French ISPs to point
> their
> > > name servers at that root server.  Everybody in France would comply as
> > > otherwise there would be no internet.
> >
> > That's not how DNS works.
> 
> Saliya, I shouldn't need to explain everything in specific detail
> and you should have got the point from the use of the example.

You don't need to explain everything in specific detail; your example was
demonstrably incorrect.  The explanation I gave should be sufficient to
illustrate the flaw in your example; anybody that needs it explained in
more detail is welcome to ask me off list (yourself included).

> > What would happen then is that nobody in the
> > rest of the world would be able to see the .fr domain; all Internet users
> > in France (provided they were querying working nameservers) would continue
> > to be able to access www.linux.org or mail.foo.com just fine.
> 
> You certainly can't assume that everybody would do nothing about France being
> switched of.  They are invalid assumptions that you have made (see below).
> 
> So what rot.  What do you really think would happen in the United States if
> big
> business could not acess France for more than a couple of hours?  Every big
> ISP
> in the US would be put under enormous pressure to point to a root server that
> included France.

That's hypothesis; I couldn't say whether that would be true one way or
another. My personal experience of the US w.r.t the Internet (no offence
to any Yankees, btw :) is that they don't really give a toss about the
rest of the world: that we're tolerated by them rather than required. But
that's irrelevant to this discussion.

> You are arguing from a "static" point of view.  But it's a dynamic system.  If
> ICANN continued to refuse then they would be "dead meat".  Within hours, ISPs
> all over the world would be looking for allternative root servers to point to
> which included France.
> 
> That's exactly why I used a major country like France as an example.

There are two problems with your example:

1) The example is technically flawed (as illustrated previously)
2) It discusses the wrong situation (i.e. the removal of an existing
legacy domain, not the justification for creation of a new one).

I think we can summarize here:

"Some Sellers" want to sell new TLDs.
"Some Consumers" want to purchase these new TLDs.
"Some Sellers" do not like ICANN's policies of not creating random TLDs.
"Some Sellers"' solution to this problem is to create alternate roots.

Note that I am not discussing whether or not consumers want new TLDs (they
might, they might not, so I give the alt-root proponents the benefit of
the doubt).

> I've agreed collisions are a nuisance.  What to do is the question.

The answer to that question is 'don't setup alternate roots'. Very much
like "don't drive on the right-hand-side of the road" as opposed to "when
you are heading for a collision, brake and pull left" (in Australia :)

> I'm sorry that I confused things with analogies.  At the moment I can make a
> long distance phone call using any one of a variety of telephone companies.
> I select which one by putting a numeric prefix (say "459") in front of the
> required telephone number.

Different situation; the situation you describe is not really relevant to
this discussion: in your example, you illustrate many-disparate-numbers
mapping to a single final destination: this scenario already is possible
within the DNS and does not require an alternate root confederation to
provide it.

> That routes the call through a particular service provider who then bills me.
> But this is not a good example either, you will say.   I will shrug ;)

Well, don't use the example if you can't find a valid one. Or perhaps we
should just invoke Godwin's law right now ? Nazi! :)

> > 1) Order-n complexity; everybody that wants to add a 'new' superset needs
> > to add every superset that has been done beforehand. *not* good from a
> > 'network stability' point of view, and
> 
> Not if you have a published superset that everyone draws their subset from.

That's exactly how the DNS works *right now*; with the exception that
there is no difference between 'superset' and 'subset'.

> In other words I agree that there neeeds to be a *virtual* single root.  Just
> that it does not need to be controlled by ICANN.

Therefore, we agree. Alternate roots are bad (because we need a single
root). QED. 

And here I believe we can draw this discussion to a close. You have
illustrated what I feel to be the main arguments of all the 'alternate
root' proponents; and I feel that they have been refuted (perhaps not
superbly, but hopefully well enough for the purposes of illustration).

> Opponents of alternate roots always mix up the argument.  They say it won't
> work from a technical viewpoint and then argue on the ground of consumer
> preferences.

This isn't mixing up "the" argument. There are two separate arguments,
neither of which invalidates the other.

> Exactly.  And how long would bad business practices last?  Again you must
> think of the dynamics.  But it doesn't mean the internet won't work.  Just
> that the two .BIZes would have to sit down and negotiate.  Or sue each other.
> Or just compete to the death.

Or just register a guaranteed-non-conflicting name. Not really a tough
call, is it ?

> > That's precisely the point. What if one operator refuses to negotiate ?
> > According to the paper you quote above this makes the .foo domain unable
> > to be used.
> 
> Ships at sea agree to maritime rule.  Otherwise they crash.  Somplie as that.

But there's NO NEED for the ships to be in the same space. By introducing
the alternate root, you introduce the crash possibility. Your solution to
the problem that has *just been created* is 'they should negotiate': my
solution is 'don't introduce the problem'.

Regards,

Saliya
Received on Fri Oct 03 2003 - 00:00:00 UTC

This archive was generated by hypermail 2.3.0 : Sat Sep 09 2017 - 22:00:04 UTC