|
Simon Higgs, of Higgs Communications and a member of the TLDA, has published an Internet Draft with the ISOC defining the basics of how Inclusive Roots operate. Although it is mostly correct, there are differences in how an Inclusive Root actually does include the IANA TLDs...
A Root, by definition is the anchor point and beginning of the DNS name space. An Inclusive Root does not point to another root system (RSN, or root server network), but instead has it's own SOA and Servers. It points directly to all known Top-Level Domains via the TLD Servers answering AUTH for those zones.
It was implied in his draft below, that an Inclusive Root points to the Alternate, Deprecated ICANN legacy system's RSN for all of the IANA TLDs while pointing directly to the AUTH TLD Servers for all other TLD zones in the Inclusive Name Space. The model he describes has been implemented by some RSNs, but again, by definition, and in order to be RFC compliant, the root servers in an RSN actually point to only the TLD Servers answering AUTH for any particular TLD Zone.
Private root zones may pick and choose which TLDs they point to, in the case of a corporate Intranet, for example, but Inclusive Roots include all known, non-colliding Top-Level Domains via their AUTH TLD Servers - including the TLD Servers listed as, and answering AUTH for the IANA ccTLDs and gTLDs.
A subtle difference that is negligable from the perspective of your grandmother who is jotting down recipes from say, a domain such as MarthaStewart.FOOD, but nevertheless a noteworty difference with regards to providing stable and uninterupted DNS service to the Internet Community at large in the event that the Legacy RSN goes down.
In that event, a properly configured, RFC compliant Inclusive Root system would still deliver all of the IANA TLD zones to the subscriber regardless of any catastrophic failure in the Legacy System.
For an excellent description of how the various RSNs co-exist in the name space, this Internet draft does a great job of explaining several concepts about competing root systems and the operational DNS name space.
For a complete archive or Mr. Higgs' published Internet drafts, visit HERE
Internet Engineering Task Force S. Higgs
Internet-Draft May 2001
Category: Informational
Expires: November 2001
Document: draft-higgs-virtual-root-00.txt
Alternative Roots and the Virtual Inclusive Root
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This Internet Draft discusses the "alternate roots" and the "virtual
inclusive root", in an attempt to help clear up misunderstandings on
their use in the Internet. This document solves the problem of
duplicate colliding top level domains by identifying the "virtual
inclusive root", in compliance with the IAB's RFC 2826, "IAB
Statement on the Unique DNS Root"[1].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC2119[2].
Background
For the past 6 years or so various organizations and individuals have
implemented "alternate roots" to support their own Top Level Domains
(TLD)s[3]. The origin of these alternative roots can be found in the
rough consensus and running code behind Draft Postel[4] (which was
subverted by the gTLD-MOU, which itself was terminated upon
intervention by the U.S. Government). That ICANN (the replacement
process set in place by the U.S. Government) has since failed to run
with the ball has only caused more alternative roots to spring up.
I define the term "alternate root" to mean "a DNS root zone connected
to the Internet, but with contents that differ from the ICANN roots".
An alternate root by definition includes "alternate top level domains
(TLDs)". This is perfectly acceptable, and one example is RFC 2606
/ BCP32[5] which shows how to create localized TLDs from the reserved
TLD pool.
Impact Of Alternative Roots In DNS
The following examples show the impact to the DNS from a multiple
root zone environment. It should be noted that each root zone, as a
singular entity, is fully compliant with RFC2826. The problems
described in RFC2826 surface when the user has no ability to
determine which root zone is being used for a particular transaction.
Each example also is marked as "STABILIZING" or "DESTABILIZING". This
is an important concept to grasp. The primary fallacy that must be
overcome is contained in the following set of statements:
"If a non-ICANN root service mounts a new TLD without ICANN
permission, this is defined to be destablizing."
and
"If ICANN corrects this situation by adding a conflicting TLD to
the ICANN ROOT, this is defined to be stabilizing."
There's no other way to say this: THE ABOVE STATEMENTS ARE WRONG!
The fact is that there is no conflict and no harm to the internet
until the 2nd version of a given TLD (the duplicate) is created.
In order to remedy this, the correct statements are as follows:
1. If any root service mounts a new TLD which does not conflict
with a pre-existing TLD, this SHOULD be defined as stabilizing.
2. If any root service mounts a new TLD which conflicts with a
pre-exisitng TLD, this SHOULD be defined as destabilizing.
Therefore, any new TLD which conflicts with a pre-existing TLD is
destabilizing, no matter where it comes from. The following examples
illustrate which is correct, and which is not correct:
Example 1 (STABILIZING):
ICANN Alt
root root
/|\ /|\
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
.com............ .com....... .biz
Example 1 does not create any TLD conflicts. The Alternate Root,
has been enhanced by the inclusion of the .biz TLD. Both roots
use the legacy root, now maintained by the US Government (ICANN
root), as the baseline.
Example 2 (STABILIZING):
ICANN Alt Alt
root root(A) root(B)
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
.com............ .com....... .biz(A) .com....... .biz(A)
Example 2 does not create any TLD conflicts. Both Alternate Root A
and Alternative Root B have been enhanced by the inclusion of the
.biz(A) TLD. The important thing to note is that the same .biz TLD
is supported by both Alternative Roots. All roots use the legacy
root, now maintained by the US Government (ICANN root), as the
baseline.
Example 3 (DESTABILIZING):
ICANN Alt Alt
root root(A) root(B)
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
.com............ .com....... .biz(A) .com....... .biz(B)
Example 3 creates a TLD conflict. Both Alternate Root A and
Alternative Root B have .biz TLDs, but these TLDs are not
coordinated, or peered, and therefore duplicate zones may exist.
Note that all roots use the legacy root, now maintained
by the US Government (ICANN root), as the baseline.
Example 4 (DESTABILIZING):
ICANN Alt Alt
root root(A) root(B)
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
.com........biz(C) .com....... .biz(A) .com....... .biz(A)
Example 4 creates a TLD conflict. Both Alternate Root A and
Alternative Root B have been enhanced by the inclusion of the
.biz(A) TLD. These .biz TLDs are coordinated (or peered) and are
conflict free. Adding a different .biz(C) TLD to the ICANN root
causes a conflict, and therefore duplicate zones may exist. Note
that all roots use the legacy root, now maintained by the US
Government (ICANN root), as the baseline. As you can see, this
example causes a bigger (META) problem, in that it changes the
supported baseline of TLDs that all the other roots are supposed
to recognize.
Alternate Roots do in fact exist. No one can prevent them from
existing, because the selection of a root zone to point to is a
voluntary act by DNS name server administrators and end-user client
software.
Name Conflicts
Name conflicts are generally considered a bad thing. If company "A"
uses the ICANN Root, and company "B" uses an Alternative Root, then
"A" and "B" will see identical versions of all the TLDs that both
roots support (such as .COM). Company "B" will also benefit from the
additional TLDs visible from the Alternative Root. So far, so good.
The problems arise when two roots do not support the same TLD manager
for a given TLD. As identified in RFC1591:
The designated manager must be equitable to all groups in the
domain that request domain names.
and
Significantly interested parties in the domain should agree that
the designated manager is the appropriate party.
Obviously, if there is a disagreement, it is possible to create a
duplicate TLD, in a different root, and managed by a different party.
This will lead to the inevitable delegation of duplicate domain names
(and thus create the name conflicts).
Disagreements are caused by a number of factors. Lack of entry into
a particular root zone is currently the primary cause of new root
zones (the Alternative Roots) being created.
So what happens when a duplicate domain name is created? Quite simply,
a number of things in the DNS break. These breakages happen in all
the root systems, including those roots that don't support either
version of the conflicting TLD.
The first visible sign will simply be the domain names resolving to
different IP addresses depending on which root zone is being
supported. Company "A" may put its web page in .biz(A), and Company
"B" may put its web page in .biz(C). Internet users will only be able
to reach Company "A" by using root zones supporting the .biz(A) TLD,
and Company "B" by using root zones supporting the .biz(C) TLD.
The second visible sign will be email failures. Internet users can
send a message to a
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
, but there can be two separate
sets of recipient mail servers for example.biz depending on which
root zone is used (.biz(A) or .biz(C)). To complicate this further,
each intermediary mail server that the message is routed through,
will only pass the message on to the .biz mail server from the root
that it resolves. It's quite possible that a message sent within a
particular root zone could "leak out" of that root zone via an
intermediary server that supports a different root zone. Lastly, as
soon as the email path finds a non-supporting mail server, the
message is bounced.
The third visible sign (see Example 5) is the most deadly. DNS
nameserver (NS) record pollution. This is where the NS name records
for a domain name are identical, but resolve to different IP
addresses depending upon which root zone is queried. With the
caching effect of the DNS, an NS record from one root zone may
become cached in a nameserver from a different root zone. Any
subsequent queries will point to the server for the domain name in
the other root zone.
Example 5:
.biz(A) .biz(B) in-addr.arpa
/|\ /|\ /|\
/ | \ / | \ / | \
.. | .. .. | .. / | \
| | / .. 1.2.3.4->sex.biz
sex->1.2.3.4 sex->4.3.2.1 /
/|\ /|\ 4.3.2.1->sex.biz
/ | \ / | \
.. | .. .. | ..
| |
ns1->1.2.3.5 ns1->4.3.2.2
Eventually, these problems will become magnified as more duplicate
domain names are created. To solve this, we create a meta level
solution, called the "virtual inclusive root".
Virtual Inclusive Root
The above discussion of name conflicts underscores a fundamental
point: DNS wasn't designed to deal with name conflicts.
The fundamental design goal of the DNS is to provide unique
and stable names for certain resources on the Internet. A "resource"
may be, for example, an IP address (or, in some cases, a group of IP
addresses), an email server, or a portion of the Domain Name Space
itself. The resources are represented by objects in DNS; the
fundamental service provided by the DNS is retrieval of an object,
given the name for the object.
The names provided by the DNS are structured in a hierarchical
manner, which allows the management of the names to be distributed.
Instead of a single gigantic name registry, the registration of names
can be spread across many registries.
The visible DNS hierarchy starts with what are called "Top Level
Domains" (TLDs). The next level of the hierarchy is made up of
"Second Level Domains" (SLDs), the level are "Third Level Domains"
(3LDs), and so on. The familiar ".com" is a TLD, "example.com" is a
SLD, "an.example.com" is a 3LD. "this.is.an.example.com" would be a
domain name with 5 levels.
So how do we do that if there is more that one root zone? The answer
is the Virtual Inclusive Root. It's nothing more than applying
RFC2826 to create a larger, virtual, root zone comprised of the sum
of all the variations of local root zones.
Example 6:
ICANN Alt Alt
root root(A) root(B)
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
.com(A)... .net .com(A).... .biz .com(A).... .web
From the above example (Example 6), the Virtual Inclusive Root would
consist of the .COM, .NET, .BIZ, and .WEB TLDs (all roots support
the same .COM TLD).
The Virtual Inclusive Root can be considered the best view of
consensus and co-operation for the DNS name space.
Co-ordinating The Virtual Inclusive Root
Obviously, conflicting TLDs cannot be supported in the Virtual
Inclusive Root.
The first basic rule of domain name registration is that the first
eligible applicant to register a domain name receives the exclusive
delegation of that domain name. This is traditionally known as
"first come, first served" (FCFS).
The second basic rule, as identified in the examples above, is that
there is no harm done to internet until a duplicate top level
domain is created. Users may not be able to resolve a domain name
that exists in a top level domain from a different root zone. But
this is no different to today, and does not break the DNS overall.
Adding the TLD to the Virtual Inclusive Root solves this problem.
The third basic rule is that there is no limit to the number of top
level domains that can be put in the DNS. The DNS is recursive and
the recent examples of several million domain names registered in
.COM shows that this is possible. The reality is that the demand
for TLDs is not that high.
The main objection to the virtual inclusive root is that it really
only raises the root zone up a level and that someone, somewhere,
has the job of managing it. This is not true, as the ICANN root
zone being a "single point of failure" on the Internet is the
problem that the Alternative Roots have already solved.
The Virtual Inclusive Root is the sum of the consensus between all
root zones on the public internet. The methods for allowing
DNS clients and resolvers to resolve Virtual Inclusive Root will
be described in a different document.
Other Considerations
The United States Patent and Trademark Office has determined that
top level domains are not trademarkable. This removes any
possibility of "sunrise" claims or other trademark claims to top
level domains.
If ICANN "endorses" other roots, then it would of course coordinate
its TLD selections with them, and there would be fewer, if any, name
collisions. This is by far the most pain-free solution.
If ICANN doesn't "endorse" other roots, then it will most likely
create TLDs that conflict with ones publicly in use by Alternate Root
servers (see Example 4 above). This sets precedents directly opposed
to the IETF tradition of "rough consensus and running code". It
allows the pioneer work of developers and entrepreneurs to be taken
away at the whim of others.
ICANN could also try to make it illegal to run an alternate root.
This would involve regulating the configuration of every computer
connected to the Internet, and defining what technology and service
provider everyone had to use. It would be like a law dictating that
everyone had to use the same government approved computer operating
system to avoid "instability."
The FCFS method of registration has recently been co-opted by ICANN
for financial gain, by the registry/registrar community (there is a
major kick-back in fees paid to ICANN by the registries and
registrars) for the benefit of the intellectual property community
(who are paid to secure domain names). The internet user community
is the loser, paying several times over just to secure a single
domain name. The Alternative Roots exist, at the behest of the
internet user community, to bypass this kind of profiteering.
Security Considerations
This memo does not introduce any new security issues.
This memo does not address DNSSec issues.
Acknowledgments
The author would like to thank Karl Auerbach, Scott Bradner,
Milton Mueller, Brian Reid, Richard Sexton, and Einar
Stefferud for their constructive comments.
References
1 Internet Architecture Board, "IAB Technical Comment on the Unique
DNS Root", RFC 2826, May 2000
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Postel, J., "The IANA's File of iTLD Requests",
http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html
4 Postel, J., "New Registries and the Delegation of International
Top Level Domains"
http://www.newdom.com/archive/draft-postel-iana-itld-admin-02.txt
5 D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", BCP32,
RFC 2606, June 1999
Author's Address
Simon Higgs
Higgs Communications
P.O. Box 4519
Sunland, CA 91041-4519
Phone: 818-352-3208
Fax: 818-352-0030
Email:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
###
|
