North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Reality Check

  • From: Timothy R. McKee
  • Date: Wed Mar 14 20:05:12 2001

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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
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.

Tim

> -----Original Message-----
> From: Jim Dixon [mailto:[email protected]]
> Sent: Wednesday, March 14, 2001 16:13
> To: Timothy R. McKee
> Cc: [email protected]
> 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-----