Reality Check

Jim Dixon jdd at vbc.net
Wed Mar 14 22:53:04 UTC 2001


On Wed, 14 Mar 2001, Timothy R. McKee wrote:

> Yes, we fix things when they break.  We have done so for years.  What I
> don't want to see happen is for us to allow a system to be put in place that
> CAN'T BE FIXED.

With all due respect, you are ignoring everything that I have said.
  
We are already dealing with a system that is far more complex than
the one that you are describing as unfixable -- and we are coping 
with it quite well.
 
> If several 'pirate' TLD providers all offer up the same TLD how do we fix
> conflicts?  No matter which one we choose to put first in our search list we
> will end up being sued by the others...  It's guaranteed.  The only legally

I must be missing something.  

Various parties have been providing access to alternative roots of one
kind or another for several years.  Who is suing anybody?  

What would the grounds for the lawsuit be?

And does this sudden shift in arguments mean that you are conceding
my main point, that there are no serious technical difficulties 
involved?

> defensible mechanism is to not allow ANY patches - that is to say we enforce
> the only root zone authority that has any real recognized legal standing.  I
> know if I started one of these companies I would start looking for legal
> targets immediately....   There's more potential money there than in the
> registration business itself.

I think that in the real world if several different registries offered
the same top level domain and this resulted in any ambiguity, no one
would use the top level domain.  The market would sort out any 
ambiguity very very quickly.  

> > -----Original Message-----
> > From: Jim Dixon [mailto:jdd at vbc.net]
> > Sent: Wednesday, March 14, 2001 16:13
> > To: Timothy R. McKee
> > Cc: nanog at merit.edu
> > Subject: RE: Reality Check
> >
> >
> > On Wed, 14 Mar 2001, Timothy R. McKee wrote:
> >
> > > > Bear in mind that in many cases, this is an illusion.  They aren't
> > > > accessing the same machine at all.  Someone is using round robin DNS
> > > > to map one name into several IP addresses, or a Local Director to
> > > > map one IP address into many IP addresses, or there is some other such
> > > > substitution being employed.
> > > >
> > > > In some cases the party serving the data is involved in the illusion.
> > > > In others, as in transparent proxying, someone along the way is
> > > > intervening.  This is often silent and may have the consent of neither
> > > > the user/client or whoever is running the intended target.
> > >
> > > Yet in all cases, except where something is physically broken or out of
> > > synch, the initiating user and the terminating server expect
> > that access to
> > > information or services via a documented public mnemonic URL
> > will provide
> > > the same information (or a cached copy of it) to every user
> > globally.  If it
> > > doesn't WE are the ones that are held responsible by the users.
> >
> > That may be true.  Nevertheless, the existing system works.  Whenever
> > it fails to work, we fix it.
> >
> > > > My point is that we are already in the world that you are warning us
> > > > about.  People are happily using one address space within their
> > > > company and quite another to talk to the outside world, with NAT
> > > > mediating between the two.  Their internal DNS is also different from
> > > > the DNS seen on the global Internet.  And it all seems to be working
> > > > exceedingly well, despite the fact the games people play with IP
> > > > addresses and domain names are becoming very subtle indeed.
> > >
> > > But once again, when they access or publish a PUBLIC URL, they have
> > > expectations  that it will work and it will work the same for everyone
> > > regardless of location or ISP affiliation.  I don't consider internal
> > > network workings to be public in nature.
> >
> > And that is of course true.  But we still have a working system,
> > one in which we, the network operators, ensure that our customers
> > are content that the illusion with which we present them is correct.
> >
> > Now consider the relative complexity of the systems involved.  In
> > one, there are at least tens of thousands of address fiddles in
> > operation, cases in which the machine you think you are accessing
> > is not the machine that you are really accessing.   This goes on
> > all the time.  Moderately often there are glitches.  When there
> > are, we fix it or complain to someone who can.  Generally speaking,
> > problems get resolved fairly quickly.
> >
> > In the other case, there are a couple of hundred mappings from
> > domain names like .COM, .UK, .NET, .FR into the IP addresses of name
> > servers authoritative for these names.  Someone else pointed out
> > that the information involve is around 60 KB in all.  Please
> > convince me that the world's ISPs are not capable of managing
> > this simple task.
> >
> > Spelling out the obvious: let's say that VBCnet started referring
> > our customers to the wrong name server to resolve names in .COM.
> > How many minutes would it be before the phones began ringing off
> > the hook?  I can assure you that we would fix it really fast, and
> > take steps to make sure that we didn't screw up again.
> >
> > --
> > Jim Dixon                  VBCnet GB Ltd           http://www.vbc.net
> > tel +44 117 929 1316                             fax +44 117 927 2015
> >
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> 
> iQA/AwUBOq/kbBRIXzEQLahvEQI+6wCgiiEdWjITchTh0nM/5kb95ilYWwYAoIXg
> ZgTwPi6yCAl500LYyhK8R8iK
> =5MsO
> -----END PGP SIGNATURE-----
> 
> 

--
Jim Dixon                  VBCnet GB Ltd           http://www.vbc.net
tel +44 117 929 1316                             fax +44 117 927 2015





More information about the NANOG mailing list