More than 5 years ago I predicted what the Chinese government announced today. What happened today: http://english.people.com.cn/200602/28/eng20060228_246712.html http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET-POLICY-MII-DOMAIN%20NAME-DNS http://www.domainesinfo.fr/vie_extensions.php?vde_id=859 http://politics.slashdot.org/politics/06/02/28/1610242.shtml http://news.com.com/China+creates+own+Internet+domains/2100-1028_3-6044629.html was obvious and quite easy to foresee. Addressing the requirements of a very real international multi-root environment is also not all that hard and will likely naturally evolve. But there is more that can be done. The Internet technical community is now given a unique opportunity to expand the domain notation and even address past mistakes and fix the domain backwardness problem. About 4 years ago, in a note with the subject of: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! I re-sent the write up (dated Jan 1999) for what needs to be done to move things forward. It is included here again below. Obviously, IETF is not fit to move this forward. If anybody translates this plan into Chinese, please email me a copy. -- Mohsen BANAN To: Internet Technical Community <ietf at ietf.org> Subject: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! From: public at mohsen.banan.1.byname.net Date: 06 Aug 2002 06:42:23 -0700 Sender: owner-ietf at ietf.org Good! After many years, the Internet technical community (save ICANN and IETF cult's chiefs) has now arrived to the general recognition that the concept of parallel root server clusters are in fact practical, workable, stable and democratic. It may now be a good time to re-visit other DNS problems and recognize that they can also be solved. Most notably, The DNS Notation Backwardsness. Parallel root server clusters and the fixing of the DNS Notation Backwardsness problem are very related and can be done at the same time. I explained all of this in reasonable detail more than 3.5 years ago. It is comforting to see that parts of the solution that I proposed is now in place. Below is the main email from the thread that I introduced in 1998/1999. At that time, with hope, I said: I believe it is only now that we have an opportunity to plant the right seeds so that the "problem" can be fixed over time. >>From a historic perspective it is worthwhile noting that shortly after Bob Allisat suggested that the IETF build on the concepts that I had introduced, he was banned from the IETF mailing list by the then IETF Chair, Fred Baker. While I address this message to the Internet technical community, if in fact IETF does not stand for Innovation Extermination Task Force, then perhaps even IETF can get involved in cultivation of these concepts. --- 1999 Original Message Follows --- To: IETF Mailing List <ietf at ietf.org> Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! Date: Tue, 26 Jan 1999 00:41:34 -0800 (PST) [This is a summary response which covers comments which were in reply to my: <199901220641.WAA11066 at rostam.neda.com> message with the subject of: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! dated Thu, 21 Jan 1999 22:41:13 -0800 (PST).] I ended my previous note, by saying: >>>>> On Thu, 21 Jan 1999 22:41:13 -0800 (PST), Mohsen BANAN <mohsen at neda.com> said: Mohsen> ... Mohsen> Now, after all of this if there was to be an Mohsen> acknowledgment that there is an architectural Mohsen> problem here and that this is not a "strings Mohsen> parsing" issue which can go either way, then Mohsen> may be we can work on solutions .... Many got the point -- that there is a "notation backwardness" problem. For example: >>>>> On Fri, 22 Jan 1999 08:42:32 -0000, "mark.paton" <mark.paton at btinternet.com> said: mark> I hate to admit it but he has a point! and: >>>>> On Fri, 22 Jan 1999 14:50:41 +0400, Peter Dawson <peterdd at gto.net.om> said: Peter> ... Peter> How come the folks don't admit the mistakes and just Peter> keepcontinuing.. ?? we all understand it is human to err.. !! and: .... Now, we just have got to leave behind those who after all of this, still don't get it and can't (or don't want to) follow. I -- and many others -- have known about this notation backwardness for more than 10 years. Prior to last week, I had never brought up this issue publicly. There is a good reason why I chose 1999 as the time to bring it up. That is because, I believe it is only now that we have an opportunity to plant the right seeds so that the "problem" can be fixed over time. Taking advantage of this opportunity to fix it is a lot more reasonable than "living" with it. >>>>> On Fri, 22 Jan 1999 04:14:55 -0500 (EST), "Theodore Y. Ts'o" <tytso at MIT.EDU> said: Theodore> ... Theodore> Whether or not you call this a "Problem" depends on your point Theodore> of view. But this is reality. Live with it. Ted, you live with it. If you want to. I am an engineer. I try to fix problems when the opportunity presents itself. Please consider what I refer to as the "opportunity to plant the right seeds", with an open mind for a moment. May be it is workable. May be it is not. Worstcase, we live with it. I want to try. Yes. This problem has widespread roots. >>>>> On Fri, 22 Jan 1999 10:09:02 -0800 (PST), Ned Freed <Ned.Freed at innosoft.com> said: Ned> I am in complete agreement with Ted here. I also have issues with the way Ned> things work and the way things were done, but I recognize that this stuff is Ned> far too widely deployed at far too many levels to change now. Ned, I understand (and respect) the significance of the installed base as much as the next guy. That is why I don't refer to this as a "quick fix" but as a "planting of the seeds" type of an approach. In order to understand what I am proposing we have to consider it in the larger context of Domains and DNS ambiance of 1999. Let's put everything on the table and take a quick look. - We have a DNS-mess grid-lock. At least according to some (me included). The idea of expanding top level domains have gone nowhere. Introducing competition at the root-server and registration level has gone nowhere. General confidence in progress is low ... - Updates to DNS Software (both client and server) for beyond IPv4 addresses are needed. - Updates to DNS Software (both client and server) for security, public keys, certificates, ... are needed. - As phone numbers and Domains keep coming together, the domain notation's backwardness is becoming more visible and significant. - ... Since it appears that we have to go through a global DNS client software update, it makes sense to address all of the above issues more or less in one shot. Now, I am suggesting that as we consider updates to DNS Software (particularly client), it is reasonable and good to plant the seeds for a forward domain notation as well. I am also suggesting that we loosely link the new notation to the concepts of completely independent and seperate Top Level Registries and independent root-server clusters. [Note that these two concepts (notation and multiple independent root-server cluster) are not necessarily connected to each other.] Let me explain what I consider a workable approach that will address a number of current DNS challenges. First, I need to introduce some names for the needed concepts. Let's call: Plain Old Domain Notation (PODN): --------------------------------- today's domain notation. For example: www.ietf.org Forward Domain Notation (FDN): ------------------------------ The new forward notation for domains. This notation includes a "Name Resolution Selector (NRS)" For example: r1:org.ietf.www Backward Domain Notation (BDN): ------------------------------ The new backward notation for domains. This notation includes a "Name Resolution Selector (NRS)" For example: www.ietf.org.r1 BDN is same as PODN but has the the Name Resolution Selector on top of what used to be the TLD. Name Resolution Selector (NRS): ------------------------------- An identifier which says which root-server cluster should be used. For example: r1:org.ietf.www (or www.ietf.org.r1) says use "r1" root-server cluster to resolve www.ietf.org (PODN). Note that the NRS is capable of identifying the method (i.e., protocol) in addition to the root-server cluster. Forward Bind: ------------- Updates to the bind (or its equivalent) package which includes the Forward Domain Notation as its canonical notation and which supports name resolution based on multiple co-existing but separate root-server clusters. I am claiming that the above ingredients can break the DNS-mess grid-lock and can position us to address the backwardness of the Notation over time. To look at how this all is supposed to fit together we need to consider at least the following dimensions: - The Protocols - The Resolver Software - Operation of Root-Server Clusters Then, we also need to consider the "Motivations" and "Transition". The Protocol ============ Initially, DNS requires no protocol changes. This needs to be verified by a quick proto-type or .... The Resolver Software ===================== What I call "Forward-Bind" needs to have the following key characteristics: - Support access and use of multiple root-server clusters. Presently a single /etc/named/named.ca file is used by Bind. Forward-Bind can use multiple root-server clusters and therefore multiple root cluster information is needed. For example r1.named.ca r2.named.ca ... - Support the explicit Name Resolution Selector (NRS) notation. When FDN or BDN are used, the use of the specified root-server cluster is explicit. - Support implicit name resolution selection. This is essentail for the transition period. When PODN is used, selection of the root-swerver cluster to use is determined by a somewhat static map of TLDs to root-server cluster. The assumption is that through agreement amongst root-server cluster operators there will be no duplicate TLDs across root-server clusters. If there is a problem, still the user gets to choose. - The software supports all three notations -- PODN, FDN, BDN -- from the very beginning The key attribute of this software is that by supporting choice in selection of root-server clusters, it empowers the user. Operation of Root-Server Clusters ================================= Each Root-Server Cluster runs its root serves and has its own independent registration policy. There is little, if any co-ordination that is required amongst the Root-Server Clusters. These Root-Server Clusters compete to provide the cheapest and the most reliable domain registration capabilities to their users. Something like part of ICANN can be considered the consortium of Root-Server Cluster operators which can accommodate distribution of the generally static information needed for smooth operation of what I like to call Next Generation DNS. In the interim, while use of FDN and BDN is not widespread, uniqness of TLDs and the distribution of TLD to NRS map is another thing that the consortium of Root-Server Cluster operators needs to do. Having covered what it takes to make this happen, let's see Why people may want to do this. *MOTIVATIONS* ------------- The likes of Bob Allisat want to empower the user. All kinds of people want to compete with NSI ... And, the Network must remain stable and reliable. What I am suggesting here involves no changes to the current operation. It just allows for peer universes to co-exist with the current established one. Because this idea centers around selection of the root-server by user's software, creation of these peer universes is outside of any particular authority. It is in the collective user community's interest that the Network remains stable. Therfore, we are likely not to end up with anarchy. To make this happen, no particular permission is needed from anyone. Just make what I have been calling Forward-Bind widespread and set up the parallel root-server clusters. As an example, let's say that the AOL, Netscape, Sun, ... combo wanted to mass register domains without going through NSI. They can easily make Forward-Bind widespread. Then, they can set-up their own root-server cluster. Then mass register domains (say under r2:nom such as john.smith.nom) for their users and everybody else. Now NSI has competition and the user has choice. *TRANSITION* ------------ Using the above example, initially the root-server selector map will look something like: org, net, com :r1 # Current (NSI, ...) nom, web :r2 # Example: AOL, Netscape, Sun, .. store, www :r3 # somebody else This is likely to be quite a static map which gets distributed with the software. I don't consider occasional updates to this map or addition of r4.named.ca a difficulty. Initially there can be no conflict between TLDs across root-server clusters. Once Forward-Bind is widespread, then addresses of the form acme.com.r1 and acme.com.r2 can even be used and the "no same TLD across root-server clusters" limitation goes away. Next step is to gradually transition to FDN. FDN and BDN can easily co-exist for a long time. Because FDN was planted in the Forward-Bind from the beginning, transition to FDN is a matter of its support in application protocols. This requires Architectural Leadership. But, where is that going to come from? IAB? :-) Once FDN is inside of Forward-Bind, it is possible for us to define new network object identifiers such as: r2:net.ByNumber.1.888.555.2222:voiceOverIp:"collect" for new protocols and at least move forward with FDN. At a component level, may be there is not all that much that is new in what I am suggesting. But, may be the combination of: - Enhancing the desktop software to provide for choice and selection amongst root-server clusters. - The creation of multiple indpendent root-server clusters. - Enhancements to the notation which makes the traditional TLDs not absolute and breaks the current monopoly. - Providing the user the ultimate control and selection. is new. I think there is enough detail in this message to let people decide if this idea is workable or not. Because I think this (or some variation of it) is workable, I needed to get this out. Those who feel this is worthy of exposure in various DNS-mess related forums are welcome to forward it to other relevant mailing lists. For now I consider my part done. I know that something like this is likely to be controversial. I am likely not to further participate in this thread. You don't need to insult me on that account. Questions and comments that are expressed politely have a better chance of tempting me to respond. ...Mohsen _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf