ICANN ICANN Email List Archives

[comments-name-collision-26feb14]


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

Afnic's comments to name collision report

  • To: <comments-name-collision-26feb14@xxxxxxxxx>
  • Subject: Afnic's comments to name collision report
  • From: "Pierre Bonis" <pierre.bonis@xxxxxxxx>
  • Date: Mon, 31 Mar 2014 18:59:57 +0200 (CEST)

Please, find below the comments made by Afnic to the report on name 
collision issued by JAS.



Sincerely,



Pierre Bonis





                                                                             
                                                                             
                                                                             
            ******

Afnic welcomes the opportunity to comment the recommendations made by JAS in 
their report, in order to mitigate the name collision risks.



As a back-end registry for 17 new gTLDs, and especially for the two new 
gTLDs .bzh and .paris, who respectively received lists of 2001 and 18767 
blocked names 
<http://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en>
 
http://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en 
, 
Afnic welcomes the improvements brought by JAS in their report, but is still 
concerned by the methodology and the rationale used by ICANN to propose a 
“One Size Fits All” response to the name collision problem.



1.     About the severity of the problem.

As JAS report states on the very beginning (page 1) and reiterates on 
several occasions later :

“We do not find that the addition of new Top Level Domains (TLDs) 
fundamentally or significantly increases or changes the risks associated 
with DNS namespace collisions.”

“Over the course of the study, JAS found no evidence to suggest that the 
security and stability of the global Internet DNS itself is at risk” (page 
2)



Afnic commends ICANN dedication to the security and stability of the 
Internet, but wonders why, given the fact name collisions are reported to be 
a well-known threat and the blocked names list has been published since 
November 2013, there is still a need to block all these names for a period 
of 120 days after delegation of the TLD.



2.     About the risk mitigation proposals

The proposal to block all the names considered risky, for a 120-day period 
of time, seems somehow arbitrary. There should be a clear path for 
registries to bring evidence they have already deployed risk mitigation 
plans on various names, thus allowing them to open these names for 
registration from the beginning of the launch process of their TLD. Out of 
several thousands of blocked names through the initial report, some names 
are of very high importance to the TLD, especially when they are related to 
important companies that could be interested to register their names.

In such a case, registries should be allowed to engage a specific mitigation 
plan that could be validated by ICANN, prior to the general availability of 
the TLD.



3.     About ICANN responsibility to mitigate the risk



As JAS clearly expresses the need for ICANN to engage directly with system 
operators to ask them to comply with best practices and therefore to stop 
using internally TLDs that are delegated to the root zone, the requirements 
proposed to mitigate the collision risk are almost exclusively made to the 
registries (the systems operators appear not to be sufficiently involved 
with their large share of mitigation). The list of blocked names published 
by ICANN in November should allow ICANN engaging, along with its customers 
(the registries) dialogue with ISPs and systems operators to track the 
queries made that lead to these lists, determine the sources they are 
originated from, and inform directly the operators that the TLD is going to 
be delegated.

If the blocked names lists are really relevant (and we still have some 
concerns about the methodology used to build them), we do not see other ways 
to really mitigate the name collision risk, and particularly do not see how 
uniformly applying a 120-day period to each new gTLD would significantly 
change the current situation, except the potential of dramatically weakening 
the new TLDs launch programs.



As for the detailed recommendation made in this report, Afnic would advise 
the following:



Recommendation 2: With regard to recommendation 2, Option 4 discusses about 
de-delegating the impacted TLD as a feasible option. We completely disagree 
that it is a feasible option, since research points out that name collisions 
are not a new phenomenon, and will not be mitigated definitely just by 
providing mitigation measures to the SLD list to be blocked, currently 
provided by ICANN for each new gTLDs. There are possibilities that 
collisions occur with new strings in the future. Hence, the possibility of 
de-delegating a gTLD by ICANN should be completely removed.
Elaborating into 
the different options, it is not clear from the report who is the "impacted 
party"?. From our understanding, the impacted party could either be:

1.       The gTLD registry under whom the name collision has occurred;

2.       The SLD owner whose domain name is the cause of collision;

3.       The end user who is impacted as the result of the name collision.



As per our knowledge doing our own research on name collisions, to mitigate 
it, it is important to identify the source of the collisions. In order to 
identify the end source, in most cases, the ISP's collaboration is 
important. In addition to disseminating information about the introduction 
of new gTLDs and the issues surrounding name collisions in the fora 
frequented by system operators, ICANN should be able to rope in major ISP's 
for real mitigation.






RECOMMENDATION 4: This should be ensured only as the last possible 
measure. ICANN should take into account the SLAs between the registry and 
the SLD, thus suddenly blocking a SLD could impact the registry 
economically. An example could be blocking a string in a “Pioneer list”. 
Rather, ICANN should help in all ways the registry to identify the source of 
name collisions and mitigate them.











RECOMMENDATION 5: Again, rather than ICANN forcing the registries to block 
the SLDs, ICANN should enable further research in possibly identifying the 
root cause and mitigating them. The best possible way for a short and medium 
term is for ICANN to help each registry is to have a process in schedule to 
mitigate name collision rather than just blocking the SLDs






Recommendation 6: The reason for the 120-day period for controlled 
interruption is not clearly explained in the report. If a registry is 
capable of demonstrating to ICANN that it has mitigated the name collision, 
the concerned SLD should be activated immediately. Contractual obligation 
vis-a-vis the registry and the SLD owner sometimes may not allow the 
registry to block the SLD for 120 days.



RECOMMENDATION 7: As recommended in the discussions in the collisions 
mailing list for a better visibility, instead of redirection to 127.0.53.53, 
ICANN should create a public web server which redirects all the name 
collisions related queries. The redirected query of course should be 
stripped of all sensitive data.



RECOMMENDATION 11: In addition to this recommendation, it would be 
recommended that ICANN rope in major ISPs to contribute to the public 
archive subjected to removing all information concerning privacy of the end 
user./







Attachment: name collision public comment.pdf
Description: Adobe PDF document



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

Privacy Policy | Terms of Service | Cookies Policy