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