ICANN ICANN Email List Archives


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

Uniregistry Reply Comment

  • To: "comments-name-collision-05aug13@xxxxxxxxx" <comments-name-collision-05aug13@xxxxxxxxx>
  • Subject: Uniregistry Reply Comment
  • From: Bret Fausett <bret@xxxxxxxxxxxx>
  • Date: Tue, 17 Sep 2013 18:08:05 -0500

Uniregistry Follow-Up Comments

Uniregistry submits these additional comments on on the reports entitled "Name 
Collision in the DNS" and "New Collision Risk Mitigation Proposal" 
  These comments supplement our prior note posted on August 27, 2013 ate at 

ICANN Should Not Yield Its Mandate To Uncontrolled Private DNS

The issues raised in the  reports on name collision have been known for more 
than a decade. In addition to publications which others have pointed out, prior 
publications on the topic include:

• 2001: "DNS Measurements at a Root Server", CAIDA: 
• 2010: "Understanding and preparing for DNS evolution", CAIDA, 

When ICANN began to establish new TLDs in November, 2000, ICANN made clear that 
it was using those seven selected TLDs to begin a period of study and inquiry 
to fully understand the effects of new top level domains. Between the 2000 
round and the present gTLD round, several sponsored TLDs were also established. 
 At various points during both of those rounds, it was argued by some that 
ICANN's introduction of new TLDs would disrupt expectations premised on the 
previous non-existence of such TLDs in the ICANN root.

ICANN addressed the topic of independent and uncoordinated uses of DNS, which 
rely on prospectively incorrect assumptions of the non-existence of 
ICANN-authorized TLDs in ICP-3 "A Unique Authoritative Root for the DNS 
(http://www.icann.org/en/about/unique-authoritative-root).  ICANN has never 
retracted nor amended this fundamental policy statement, and those who have 
submitted applications to ICANN's present new gTLD program have relied upon 
ICANN's commitment to carrying out its own policies, including ICANN's 
commitment to the principles elucidated in ICP-3, which specifically addressed 
private uses of TLD labels by network engineers who assume the non-existence of 
such labels in the ICANN root:

"Some private organizations have established DNS roots as alternates to the 
authoritative root. Some uses of these alternate roots do not jeopardize the 
stability of the DNS. For example, many are purely private roots operating 
inside institutions and are carefully insulated from the DNS. Others are purely 
experimental in the best traditions of the Internet and are carefully managed 
so as not to interfere with the operation of the DNS. These both operate within 
community-established norms.


Given the design of the DNS, and particularly the intermediate-host and cache 
poisoning issues […] special care must be taken to insulate the DNS from the 
alternate root's effects. For example, alternate roots are commonly operated by 
large organizations within their private networks without harmful effects, 
since care is taken to prevent the flow of the alternate resource records onto 
the public Internet."

In contrast to the current suggestions that ICANN should defer to uncoordinated 
use of TLD labels in private networks, the actual "risk" spelled out in ICP-3 
would flow from ICANN subordinating its role to the uncoordinated use of TLD 
labels such that "ICANN will be required by their very presence and force of 
numbers to recognize in perpetuity these pseudo TLDs, inhibiting new TLDs with 
the same top-level name from being launched through the community's processes." 
 Opponents of ICANN's coordinating function, as served by the ICANN new gTLD 
program, suggest ICANN should reverse itself and now begin to defer to the 
uncoordinated and improperly controlled use of DNS operators.

We agree with the unambiguous conclusion set forth in ICP-3:

"No current policy would allow ICANN to grant such preferential rights. To do 
so would effectively yield ICANN's mandate to introduce new TLDs in an orderly 
manner in the public interest."

There is no reason to change ICANN policy on that point now.  What is more 
attenuated in the present context is that the purported "stability and 
security" concerns are not actually being raised by the network operators 
employing private DNS, such as the alternative root operators to whom ICP-3 was 
intended, in part, as a response.  This time, such concerns are being raised by 
those who have long opposed ICANN's coordinating function. What is being asked 
of ICANN here is, at long last, to subordinate its primary function of 
coordinating the authoritative root in deference to the uncontrolled use of 
private DNS premised on improper design assumptions.

Promotion of Competition and Consumer Choice

While the recent concerns have been couched in terms of ICANN's obligation to 
preserve security, stability, and resilience, these are not ICANN's only 
obligation.   However, preservation of security, stability and resilience 
requires that ICANN maintain its role as coordinator of the authoritative root.

ICANN is also obligated  to "promote competition, consumer trust, and consumer 
choice in the marketplace." Again, deference to improper use of DNS by 
uncoordinated operators does not promote these objectives, and encourages the 
opposite.  Indefinite postponement of the new gTLD program promotes neither 
competition nor consumer choice, and deference to unauthorized use of TLD 
labels in the public DNS invites chaos.

ICANN's mandate to preserve DNS security and stability is thus furthered by 
ICANN's mandate to promote competition and consumer choice.  These two 
objectives are not in conflict in the present discussion.  By deferring to use 
of the internet based on improper design assumptions, the potential for 
additional such conflicts in the future is increased, not decreased.  Deferring 
to them as a policy matter would benefit no one but the incumbent providers of 
DNS registry services.

ICANN's role is certainly to balance risk against innovation and competition.   
Consideration of those objectives must take into account the consequences of 
where that balance is struck, in terms of whether it erodes ICANN's own ability 
to further those objectives.  We submit that whatever short term disruption may 
result to private DNS applications leaking into the public DNS root are best 
addressed by the affected network operators at this time.  In the long term, 
security and stability is best served by addressing improper design assumptions 
on a distributed basis now, rather than to encourage erosion of ICANN's 
coordinating function by deferring to uncoordinated activity outside of the 
ICANN process, and thus limiting competition and consumer choice as well.

Other Comments Submitted

Uniregistry is in with the comment entitled  "Mandatory Notifications are 
Ineffective and Risky" submitted by Daniel Karrenberg of RIPE NCC 

Uniregistry further agrees with much of the material in "Donuts Comment 
Regarding Proposal to Mitigate Name Collision Risks" 
 with the caveat that the Interisle study was not hasty or flawed, as suggested 
by Donuts.  However, the Interisle study should be considered as having opened 
a discussion rather than precluding one.  Moreover, we are unwilling to 
speculate that the raw data used by that study has been subject to intentional 
manipulation by third parties.

We also agree with DotHome Inc's insightful comment on "Name Collision" posted 

    - - - -

Finally, Uniregistry would like to thank the members of the Interisle study 
team.  We believe that they have indeed identified possible risks to certain 
parties operating outside of ICANN principles embodied in ICP-3. We accept the 
Interisle study as an unbiased and factual assessment, and we look at the 
Interisle report as an opportunity for ICANN to confirm its commitment to its 
mandated objectives, policies and principles.

Bret Fausett, Esq.
Counsel to Uniregistry, Corp.
Internet Pro APC
4640 Admiralty Way, 5th Floor
Marina del Rey, California 90292
(310) 496-5755 (Office) | (310) 985-1351 (Mobile)

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

Privacy Policy | Terms of Service | Cookies Policy