RE: [ga] Alternative roots

["Dassa" <dassa@dhs.org>]

|> -----Original Message-----
|> From: Roeland Meyer [mailto:rmeyer@mhsc.com]
|> Sent: Wednesday, April 25, 2001 1:07 AM
|> To: 'dassa@dhs.org'; Ga
|> Subject: RE: [ga] Alternative roots
|>
|> > One thing we should keep in mind.  If you accept these
|> > alternative names spaces as being a part of the legacy root, then
|> > there may be collisions.  I consider them private name spaces and
as
|> > such, they are not going to cause collisions, they should not be
using Internet
|> > routable addressing to reach the hostnames within.  Much
|> > the same as any business which runs its own DNS and has their own
|> > private name space.  They are not a part of the legacy root and
as
|> > such, they are private name spaces.
|>
|> A few things render this premise faulty;
|> 1) Under COM, a domain is delegated name space, not private.
|> 2) They don't cause collisions because they are delegated
|> and no one else is allowed to declare names therein.
|> 3) A business under COM is indeed under the legacy root.
|> Firewalls not withstanding.

I'm afraid I do not follow your reasoning above.  If there are
sub-domains registed under a legacy root TLD, and then hostnames under
them, they are all part of the legacy name space.  That is a different
issue to having non-legacy name space TLD's with domains and hostnames
that are not part of the legacy name space.  On one of the private
name spaces I manage I have a host with a domain in the legacy name
space acting as a gateway.  That gateway allows any hosts within the
private name space to interact with the legacy name space however,
no-one in the legacy name space can see into my private name space.
As such I have provided a means to avoid any conflicts with the legacy
name space.  The IP addressing scheme used for the private name space
is the address space provided for such private networks and is not
Internet routable.

|> > These private name spaces may grow enough to overshadow the
legacy
|> > Internet name space but at present they are a totally separate
entity
|> > and do not belong within the legacy name space.  By providing
Internet
|> > routable addressing within those private name spaces they are
actually
|> > going against the accepted RFC's that govern the legacy name
space.
|> >
|> > I run a few private name spaces myself, I do follow the rules
however
|> > and they are not routable on the Internet.  However, it  would
not be
|> > difficult for me to do so.  Many others can also.  Once  you
allow some
|> > private name spaces into the Internet name space you  will be
opening
|> > the flood gates for any private name space to make claim.  Some
of the
|> > non-Internet routable name spaces have been around for years
also.
|>
|> Even if you don't allow access from the rest of the Internet, a
conflicting
|> delegation can still effect your internal operations. For example,
I have
|> the real case where I run the VPN TLD. Were someone ELSE to get a
VPN
|> delegation in the legacy root, I could never access those hosts
because it
|> would conflict with my own VPN zone. This particular collision
scenario is
|> called "masking". In some security environments, this may be done
|> intentionally, controlling access to external systems.
|> There are various sub-scenarios where the external VPN may actually
prevent
|> your access to your own VPN systems or even let one of those
external
|> systems masquerade as one of your own (violating your security).

It is up to the network administrators to ensure their network avoids
conflicts with any external interaction they may initiate with the
Internet legacy name space.  They control their own private name
spaces and have full control over how this may be linked into the
Internet.  It does not give them any rights over determining how the
Internet name space is administered however, no more than any other
participant.

I have even seen internal (private) networks using Internet routable
IP addressing schemes, that is worse than using a conflicting name
space TLD.  Not all network administrators set up their networks
appropriately.  If there are problems with either the IP addressing or
the name space used on such networks it is up the administrators to
adjust them and fit in with any other networks they are attemting to
interact with.

Personally, the solution as I see it is for the private (alternative)
name spaces to not link into the Internet name space and to actually
become what they originally began as, alternative name spaces to the
Internet legacy name space.  Either that or to conform to the
restrictions applied on the legacy name space.

Darryl (Dassa) Lynch.

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html