ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] "Alternative roots": a big technical failure


Dear Stephane,
so called altenative roots, which actually are private directories of the inclusive namespace, are what they are: private systems. What is more interesting is what RFCs, ICANN and WSIS say about them. ICANN has dedicated the ICP-3 document to them. I was first upset reading that prodomo document. Also, I disagreed with ICANNs current policy because it is in violation the initial consensus and it impeaches the normal development of the global numeric ecosystem. I went to open roots and wrote Best Practices with Pascal Bernhard for Root Administrators and TLD Mangers, and I ran my own root.


This shown me that it was not the best way for the internet. It is not technically wrong, but it is not the adequate operationnal, societal and political solution. So, I considered testing what could be the best way. I made my homework and read carefully and with an open mind RFCs 882, 883 .. 920, 1591, ICP-1. ICP-3 is actually brillant thinking. Except that I paradoxally disagree with it when it says that there may be a time where experimentation will lead to the end of the unique authoritative root (you do not expect that from ICANN do you ? :-). I think that the unique authoritative reality is by the TLD Managers authority, because they are entrusted the authority of the registrants, and that this builds an unique authoritative matrix. This matrix may be very complex to represent the reality. This matrix is by nature unique and should be redundantly reported and managed in concert by all the concerned parties.

What is very interesting is to read RFC 883 and RFC 882. Just the begining. In the first one, Mokapetris describes the global DNS. I do not remember the words, but he says that everyone should be able to chose the source of the data he puts in its name server. He explains that the DNS is designed for many things, etc. This is the DNS we need today. In the second one, Jon Postel descibres the way it is going to be implemented and managed for the "ARPA Internet". In the RFC 920 one year later on, he descibes the constraints imposed by the "external networks" to the final namespace set-up.

I do not know who really wrote ICP-3. But I must apologize to him. Because I was very tought about it. Actually, the way I read it today after having accepted (for our test bed) his constraints (and extended them to the societal and political levels) is that he follows the evolution of the ARPA Internet towards the Global Internet. And that he is late, but r ght. The constraints we imposed in 84 are gone for a long, yet they are still stubbornly respected. I first thought it is was dumb religion, then it was commercially correct status quo, then it was political control. This is all that. But first and also it is the practical impossiblity to experiment anything else.

Obviously, Jon Postel understood it. He "hijacked the root", he proposed new TLDs. He known or felt he could go ahead. He was opposed most probably because others realized that in becoming global the system was not anymore "his" network, but everyone's network and, even him, he was not legitimate to take risks.

Now, the problem is we have no way to move ahead. ICANN can try a few TLDs. It will make a few people to think they made a big step ahead when they will stumble. The best response I heard about this problem was by someone from the BoD in 2000 (I am not sure who he was). He responded to a question from the GAC that obviously the DNS could support a million TLDs, but he was not sure the GAC could support them.

This lives us with the need for experimentation. Because, as ICP-3 says, internet always developped by experimentation. ICP-3 gave the proper limitations: non-profit, reversible, by/open to the global community, not hurting the current traffic. Our dot-root project shown us that one has to add that: one needs real traffic, real users, real domain names and real business sales and innovation to carry a proper testing. This is feasilble in using what we called "ULD" (Upper/User Level Domains). These are SLD/TLD aliases : SLD in normal life, TLD in test name space. We also discovered that one needs a real test governance to test the management relations: no real testing may be significant if technicalities, users, e-model and administration are not tested together (and test project managers are not motivated).

Now, who is to propose a real test bed ? We paid for dot-root out of our own pockets. It gave us experience. But we cannot go further. There are other test beds. But I know none which is technical, societal (including e-model) and political except the open roots and TLDA (for what is left)? The real mistake was ".biz". Would Vint Cerf have used it and ".web" to ally with the "alt(sic)roots" and use them as a microcosm for testing, we would have the exprience and would never have had New.net.

This leaves ICANN mudded with the ccNSO to try to make TLD Managers show they accept some of its authority as a symbol of unity of the DNS. This will only lead to a split if they are not helped by the ITU, providing them an oportunistic alibi to change policy without losing face.

Now, we face the WSIS demand which is going to lead to a few big changes. Snow ball effect. We will go towards an internetworking of technologies. The GNS (genralized naming service) will probably stay compatibile with the DNS protocol, the same as IPv6.001 will stay IPv6 compatible with a univesal numbering scheme and hybrid technologies will stay compatible with TCP/IP. My only fear is that we may have a new unbalance with a too much telecom oriented architecture (virtual circuit, signal, database) bilateral model (dialog) vs the postal (datagram, mail, Words) unilateral model (monolog) when we should work out toward a service (continuity, intelligence, content) multilateral model (polylog), as called by the WSIS if you read what it implies.

Thank you not to be afraid to tell you use OSRC at home.
I suggest you try ORSN too. Strictly ICANN like root for Europe.
jfc


At 22:02 06/03/04, Stephane Bortzmeyer wrote:
Proponents of "alternative roots" often explain that these "roots" work as
well as the ICANN/USG one. It is not a big deal: operating a dozen of
nameservers with a very low traffic is not a great technical achievement. The
alternative roots would have much more problems with political, legal or
financial issues!

But even this (comparatively) simple task is not performed properly. At home,
I use ORSC, apparently one of the most serious of the alternative roots
(advices on better roots are welcome).

Today, ORSC managed to break ".org". Names in this TLD cannot be resolved
anymore, if you happen to use k.root-servers.orsc (it is the closest from me).

Here is the proper reply, as sent by a.root-servers.orsc (or an ICANN/USG root
nameserver).


~ % dig @a.root-servers.orsc NS org

; <<>> DiG 9.2.1 <<>> @a.root-servers.orsc NS org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35606
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; ANSWER SECTION:
org.                    86400   IN      NS      TLD2.ULTRADNS.NET.
org.                    86400   IN      NS      TLD1.ULTRADNS.NET.

Here is the one sent by the bogus nameserver:

~ % dig  @k.root-servers.orsc NS org

; <<>> DiG 9.2.1 <<>> @k.root-servers.orsc NS org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52691
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;org.                           IN      NS

;; AUTHORITY SECTION:
org.                    86400   IN      NS      a7.nstld.com.
org.                    86400   IN      NS      l7.nstld.com.
org.                    86400   IN      NS      g7.nstld.com.
org.                    86400   IN      NS      f7.nstld.com.
org.                    86400   IN      NS      m5.nstld.com.
org.                    86400   IN      NS      j5.nstld.com.
org.                    86400   IN      NS      i5.nstld.com.
org.                    86400   IN      NS      c5.nstld.com.
org.                    86400   IN      NS      e5.nstld.com.

(These are the old data of ".org", prior to its redelegation to PIR. No wonder
these nameservers no longer reply for ".org".)


A mail sent to ORSC technical list, tech@xxxxxxxxxxxx, was apparently not
distributed (I'm on the list and received nothing).

Mail to the mail address in the SOA, hostmaster@xxxxxxxxxxxxxxxxxxx, bounced
(62.212.100.181: Client host rejected: Access denied, it seems I'm on some
black list.)




<<< Chronological Index >>>    <<< Thread Index >>>