Subject: RE: get technical, please? , Re: Trees have one root

From: "Tony Hain" <[email-masked]>
Date: Mon, 5 Aug 2002 14:07:02 -0700

John Stracke wrote:
> ...
> 
> Or what if Fred sends mail to George and Barney; George wants 
> to reply to all, but doesn't know which of the potential 
> Barneys is the one that got the original message?

John hit the core of the problem, and it is one that the multiple root
advocates continually miss. Anyone who believes this isn't a problem
should ask their attorney about confidentiality rights if due to
ambiguity the wrong Barney gets a private message and he discloses it
publicly. The only way George can know which Barney was included by Fred
is to share a single common reference. Believing there is some out of
band mystical ability to sort out intent from a list is naive at best.

Tony

> ...

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Aug 2002 11:05:25 +0200

>band mystical ability to sort out intent from a list is naive at best.

Amen.

1. but the problem does not result from multiple root server systems, it 
results from TLD collisions
2. I may quote - and I am sure that he will want to repeat it if you ask 
him - Vint acknowledging that such a collision was created by his ".biz". I 
documented the e-mail case and he responded about web access case too.

This is IETF and only technical aspects counts. It rises however the 
following question: in reporting the DoC their support for their ".biz" to 
be included ino the arpa root, ICANN BoD did not reported that technical 
risk. Due to the technical consequence quoted here (I suppose everyone 
agree) should the IETF have not warned the DoC, so they might decide with a 
full knowldege of the technial terms?

jfc

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 6 Aug 2002 09:57:14 -0500

----- Original Message ----- 
From: "JFC (Jefsey) Morfin" <[email-masked]>
> results from TLD collisions

What TLD collisions ?
...as an example...Does .INFO collide with .INFO ?
...they look the same to me...

3:219     INFO
2002:[IPv4]:000X:03DB
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

What was that company ICANN selected to run .INFO ?

http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=info&submit=Submit
ANIC : AlterNIC : 160.79.129.192
VueDig Results : Answer = 4 : Authority = 0 : Additional = 0. 
info. 2H IN NS tld1.ultradns.net.
info. 2H IN NS tld2.nominum.com.
info. 2H IN NS tld2.ultradns.net.
info. 2H IN NS tld1.nominum.com.

BORN : Business Oriented Root Network : 213.70.103.18
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD1.NOMINUM.COM.
info. 2D IN NS TLD2.NOMINUM.COM.

CINICS : Common Interest Network Information Center Society : 216.15.192.130
Result = No Response

iDNS : i-DNS.net International : 208.184.174.7
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD2.ULTRADNS.NET.
info. 2D IN NS TLD1.ULTRADNS.NET.

LRS : Legacy Root Servers : 198.41.0.4
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD2.ULTRADNS.NET.
info. 2D IN NS TLD1.ULTRADNS.NET.

NSpace : Name.Space : 209.48.2.11
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10. 
info. 1D IN NS MEDIAFILTER.ORG.
info. 1D IN NS NS12.AUTONO.NET.
info. 1D IN NS NS00.ROOT-ZONE.NET.
info. 1D IN NS ROOT8.AUTONO.NET.
info. 1D IN NS NS1.AUTONO.NET.
info. 1D IN NS NS11.AUTONO.NET.
info. 1D IN NS ROOT3.AUTONO.NET.
info. 1D IN NS C.TLD-SERVERS.NET.
info. 1D IN NS NS.AUTONO.NET.
info. 1D IN NS NS10.AUTONO.NET.

Nnet : New.net Inc : 206.132.100.42
VueDig Results : Answer = 0 : Authority = 2 : Additional = 2. 
info. 1D IN NS TLD2.NOMINUM.COM.
info. 1D IN NS TLD1.NOMINUM.COM.

ONIC : The OpenNIC Project : 131.161.247.226
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS tld1.nominum.com.
info. 2D IN NS tld2.nominum.com.

ORSC : Open Root Server Confederation : 199.166.24.1
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10. 
info. 2D IN NS NS1.AUTONO.NET.
info. 2D IN NS MEDIAFILTER.ORG.
info. 2D IN NS ROOT3.AUTONO.NET.
info. 2D IN NS NS00.ROOT-ZONE.NET.
info. 2D IN NS ROOT8.AUTONO.NET.
info. 2D IN NS C.TLD-SERVERS.NET.
info. 2D IN NS NS10.AUTONO.NET.
info. 2D IN NS B.TLD-SERVERS.NET.
info. 2D IN NS NS12.AUTONO.NET.
info. 2D IN NS NS.AUTONO.NET.

ORSN : Open Root Server Network : 217.146.140.67
VueDig Results : Answer = 0 : Authority = 2 : Additional = 2. 
info. 2D IN NS TLD1.ULTRADNS.NET.
info. 2D IN NS TLD2.ULTRADNS.NET.

TINC : The Internet Namespace Cooperative : 64.6.65.10
Result = No Response

TPR : The PacificRoot : 204.107.129.2
VueDig Results : Answer = 3 : Authority = 0 : Additional = 3. 
info. 2D IN NS uk.universalroot.com.
info. 2D IN NS hk.universalroot.com.
info. 2D IN NS us.universalroot.com.

======

You seem to be missing a huge amount of history. The "toy" IPv4 32-bit
legacy Internet is a useful place to do experimental, Proof-Of-Concept testing
of new TLDs. It allows SLD.TLD owners to be assembled, attracted, marketed-to,
etc. prior to commercial 128-bit DNS services being deployed for their TLD.
That gets the SLD.TLD owners over the chicken-and-egg hurdle. While testing
on the "toy" Internet, the SLD.TLD owners can register in BOTH of the test POC
Registries. That provides for more reliability, and prevents having a
single-point-of-corporate failure. As long as they register the same, two,
name servers in BOTH of the test POC Registries, it does not matter what "root"
people use. All SLD.TLD paths find the right nameservers for that SLD.TLD.
Once there is a population of SLD.TLD owners, ready for the 128-bit DNS
services, the commercial providers will make the investments to serve the people
who have been playing in the 32-bit IPv4 sandbox. Here are some TLDs that
appear to have some promise.

2002 0:201 .COM  
2002 1:158 .CLUB 
2002 2:143 .FAMILY
2002 3:219 .INFO
2002 4:58 .LLC
2002 5:194 .INC
2002 6:171 .TV
2002 7:195 .CHURCH

Note, .COM will still need a second IPv4 32-bit POC Registry, to help provide
redundancy for the existing one. The .COM owners will have to pay to support
that second Registry. The THIRD .COM Registry, will then be able to deploy the
new 128-bit DNS technology and people can pay for that one also. The 128-bit
DNS .COM Registry, will of course be able to automatically check the two 32-bit
.COM Registries to make sure an SLD.COM name is properly registered and
configured. That prevents, so-called, "collisions" in the SLD.COM namespace,
because all THREE .COM Registries can synch and ensure a stable operation,
immune from a single-point-of-corporate-failure, because the new 128-bit DNS
software has been designed with many fail-over features, not found in the "toy"
32-bit DNS technology.

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt