<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true">hi all,</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">here's a blog entry that i just posted to my personal blog about namespace collision. this is mostly just repeating information that you already have. but i've decided to go on a little personal public-information campaign amongst my network-geek pals and just thought you might be interested. here's a direct link to the post -- <a href="http://www.haven2.com/index.php/archives/new-gtlds-and-namespace-collision">http://www.haven2.com/index.php/archives/new-gtlds-and-namespace-collision</a></div><div apple-content-edited="true"><br></div><div apple-content-edited="true">mikey</div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><h2><br></h2><h2>New gTLDs and namespace collision</h2>
<div class="entry"><p>This is another scratch-pad post that's aimed at a narrow
audience -- network geeks, especially in ISPs and corporations. The
first bit is a 3-minute read, followed by a 20-minute "more detail"
section. If you're baffled by this, but maybe a little concerned after
you read it, please push this page along to your network-geek friends
and colleagues and get their reaction. Feel free to repost any/all of
this.</p><p><strong>Key points before we get started</strong></p>
<ul>
<li><strong>I don't know what's going to happen</strong></li>
<li><strong>I don't know what the impact is going to be, but in some cases it could be severe<br>
</strong></li>
<li><strong>Others claim to know both of those things but I'm not convinced by their arguments right now</strong></li>
<li><strong>Thus, I think the best thing to do is learn more, hope for the best and prepare for the worst</strong></li>
<li><strong>My goal with this post is just to give you a heads-up</strong></li>
</ul><p><strong>If I were you, I'd:</strong></p>
<ul>
<li><strong>Scan my private network and see if any of my names collide with the new gTLDs that are coming<br>
</strong></li>
<li><strong>Check my recursive DNS server logs and see if any name collisions are appearing there</strong></li>
<li><strong>Start thinking about remediation now</strong></li>
<li><strong>Participate in the discussion of this topic at ICANN, especially if you foresee major impacts</strong></li>
<li><strong>Spread the word that this is coming to friends and colleagues<br>
</strong></li>
</ul><p>OK, off we go. Here's my lame depiction the difference between your
private network (with all kinds of domain names that don't route on the
wider Internet) and the public Internet (with the top level names you're
familiar with).</p><p><a href="http://www.haven2.com/wp-content/uploads/2013/08/Slide1.jpg"><img class="wp-image-1392 aligncenter" alt="Slide1" src="http://www.haven2.com/wp-content/uploads/2013/08/Slide1.jpg" height="540" width="720"></a></p><p>This next picture shows the namespace collision problem. This depiction is endorsed by nobody, your mileage may vary, etc. etc.</p><p><a href="http://www.haven2.com/wp-content/uploads/2013/08/Slide2.jpg"><img class="wp-image-1393 aligncenter" alt="Slide2" src="http://www.haven2.com/wp-content/uploads/2013/08/Slide2.jpg" height="540" width="720"></a></p><p>The new TLDs may unexpectedly cause traffic that you're expecting to
go to your trusted internal networks (or your customer's networks) to
suddenly start being routed to an untrusted external network, one that
you didn't anticipate. Donald Rumsfeld might call those external
networks "unknown unknowns" -- something untrusted that you don't know
about in advance. The singular goal of this post is to let you know
about this possibility in advance. Here's the key message:</p><p style="padding-left: 30px;"><strong><span style="color: #ff0000;">If you have private networks that use TLDs on <a href="https://gtldresult.icann.org/application-result/applicationstatus"><span style="color: #3366ff;">this list</span></a>,
best start planning for a future when those names (and any internal
certificates using those names) are going to stop working right. </span></strong></p><p>That's it. If you want, you can quit reading here. I'm going to
drop down one more level of detail before I quit, for those who are
interested in learning more.</p><p><strong>More detail<br>
</strong></p><p>Note: all the color, bold, highlighting in this section is mine -- just to draw your eye to things that I find interesting.</p><p>There are over 1000 names on that list I linked to above. Here is a
shorter list drawn from Interisle Consulting Group's 2-August, 2013
report entitled "<a href="http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf">Name Collisions in the <abbr title="Domain Name System">DNS</abbr></a>"
[PDF, 3.34 MB]. This list is the top 100 names in order of frequency
of queries that they saw in their study. I've taken the liberty of
highlighting a few that might be interesting for you to keep an eye out
for on your network or your customer's networks.</p><div> <br class="webkit-block-placeholder"></div>
<table border="0" cellpadding="0" cellspacing="0" width="681" style="position: static; z-index: auto; ">
<tbody>
<tr>
<td height="16" width="25">1</td>
<td width="51"><span style="color: #ff0000;">home</span></td>
<td width="27">21</td>
<td width="49"><span style="color: #ff0000;">mail</span></td><td width="31">41</td>
<td width="54">abc</td>
<td width="26">61</td>
<td width="54">yahoo</td>
<td width="23">81</td>
<td width="64">gmail</td>
</tr>
<tr>
<td height="15">2</td>
<td width="51"><span style="color: #ff0000;">corp</span></td>
<td width="27">22</td>
<td>star</td>
<td width="31">42</td>
<td>youtube</td>
<td>62</td>
<td>cloud</td>
<td>82</td>
<td><span style="color: #ff0000;">apple</span></td>
</tr>
<tr>
<td height="15">3</td>
<td width="51"><span style="color: #ff0000;">ice</span></td>
<td width="27">22</td>
<td>ltd</td>
<td width="31">43</td>
<td>samsung</td>
<td>63</td>
<td>chrome</td>
<td>83</td>
<td>thai</td>
</tr>
<tr>
<td height="15">4</td>
<td width="51"><span style="color: #ff0000;">global</span></td>
<td width="27">23</td>
<td>google</td>
<td width="31">44</td>
<td>hot</td>
<td>64</td>
<td>link</td>
<td>84</td>
<td><span style="color: #ff0000;">law</span></td>
</tr>
<tr>
<td height="15">5</td>
<td width="51">med</td>
<td width="27">24</td>
<td><span style="color: #ff0000;">sap</span></td>
<td width="31">45</td>
<td>you</td>
<td>65</td>
<td>comcast</td>
<td>85</td>
<td>taobao</td>
</tr>
<tr>
<td height="15">6</td>
<td width="51">site</td>
<td width="27">25</td>
<td><span style="color: #ff0000;">app</span></td>
<td width="31">46</td>
<td>ecom</td>
<td>66</td>
<td>gold</td>
<td>86</td>
<td>show</td>
</tr>
<tr>
<td height="15">7</td>
<td width="51">ads</td>
<td width="27">26</td>
<td>world</td>
<td width="31">47</td>
<td>llc</td>
<td>67</td>
<td><span style="color: #ff0000;">data</span></td>
<td>87</td>
<td>itau</td>
</tr>
<tr>
<td height="15">8</td>
<td width="51"><span style="color: #ff0000;">network</span></td>
<td width="27">27</td>
<td>mnet</td>
<td width="31">48</td>
<td><span style="color: #ff0000;">foo</span></td>
<td>68</td>
<td>cam</td>
<td>88</td>
<td>house</td>
</tr>
<tr>
<td height="15">9</td>
<td width="51"><span style="color: #ff0000;">cisco</span></td>
<td width="27">28</td>
<td>smart</td>
<td width="31">49</td>
<td>tech</td>
<td>69</td>
<td>art</td>
<td>89</td>
<td>amazon</td>
</tr>
<tr>
<td height="15">10</td>
<td width="51"><span style="color: #ff0000;">group</span></td>
<td width="27">29</td>
<td>orange</td>
<td width="31">50</td>
<td>free</td>
<td>70</td>
<td>work</td>
<td>90</td>
<td width="64">ericsson</td>
</tr>
<tr>
<td height="15">11</td>
<td width="51">box</td>
<td width="27">30</td>
<td><span style="color: #ff0000;">web</span></td>
<td width="31">51</td>
<td>kpmg</td>
<td>71</td>
<td><span style="color: #ff0000;">live</span></td>
<td>91</td>
<td width="64">college</td>
</tr>
<tr>
<td height="15">12</td>
<td><span style="color: #ff0000;">prod</span></td>
<td width="27">31</td>
<td>msd</td>
<td width="31">52</td>
<td>bet</td>
<td>72</td>
<td>ifm</td>
<td>92</td>
<td width="64">bom</td>
</tr>
<tr>
<td height="15">13</td>
<td>iinet</td>
<td width="27">32</td>
<td>red</td>
<td width="31">53</td>
<td>bcn</td>
<td>73</td>
<td>lanxess</td>
<td>93</td>
<td width="64"><span style="color: #ff0000;">ibm</span></td>
</tr>
<tr>
<td height="15">14</td>
<td>hsbc</td>
<td width="27">33</td>
<td>telefonica</td>
<td width="31">54</td>
<td>hotel</td>
<td>74</td>
<td>goo</td>
<td>94</td>
<td width="64"><span style="color: #ff0000;">company</span></td>
</tr>
<tr>
<td height="15">15</td>
<td><span style="color: #ff0000;">inc</span></td>
<td width="27">34</td>
<td>casa</td>
<td width="31">55</td>
<td><span style="color: #ff0000;">new</span></td>
<td>75</td>
<td>olympus</td>
<td>95</td>
<td width="64">sfr</td>
</tr>
<tr>
<td height="15">16</td>
<td><span style="color: #ff0000;">dev</span></td>
<td width="27">35</td>
<td>bank</td>
<td width="31">56</td>
<td>wow</td>
<td>76</td>
<td>sew</td>
<td>96</td>
<td width="64"><span style="color: #ff0000;">man</span></td>
</tr>
<tr>
<td height="15">17</td>
<td><span style="color: #ff0000;">win</span></td>
<td width="27">36</td>
<td>school</td>
<td width="31">57</td>
<td>blog</td>
<td>77</td>
<td>city</td>
<td>97</td>
<td width="64"><span style="color: #ff0000;">pub</span></td>
</tr>
<tr>
<td height="15">18</td>
<td><span style="color: #ff0000;">office</span></td>
<td width="27">37</td>
<td>movistar</td>
<td width="31">58</td>
<td>one</td>
<td>78</td>
<td>center</td>
<td>98</td>
<td width="64">services</td>
</tr>
<tr>
<td height="15">19</td>
<td>business</td>
<td width="27">38</td>
<td>search</td>
<td width="31">59</td>
<td>top</td>
<td>79</td>
<td>zip</td>
<td>99</td>
<td width="64">page</td>
</tr>
<tr>
<td height="15">20</td>
<td><span style="color: #ff0000;">host</span></td>
<td width="27">39</td>
<td><span style="color: #ff0000;">zone</span></td>
<td width="31">60</td>
<td>off</td>
<td>80</td>
<td>plus</td>
<td>100</td>
<td width="64">delta</td>
</tr>
</tbody>
</table><p>Here's the executive summary of the <a href="http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf">InterIsle report</a>.</p><p style="padding-left: 30px;"><strong>Executive Summary -- InterIsle Consulting Report</strong><strong><br>
</strong></p><p style="padding-left: 30px;"><strong></strong>Names that belong to
privately-defined or “local” name spaces often look like DNS names and
are used in their local environments in ways that are either identical
to or very similar to the way in which globally delegated DNS names are
used. Although the semantics of these names are properly defined only
within their local domains, they sometimes appear in query names
(QNAMEs) at name resolvers outside their scope, in the global Internet
DNS.</p><p style="padding-left: 30px;">The context for this study is the
potential collision of labels that are used in private or local name
spaces with labels that are candidates to be delegated as new gTLDs. The
primary purpose of the study is to help ICANN understand the security,
stability, and resiliency consequences of these collisions for end users
and their applications in both private and public settings.</p><p style="padding-left: 30px;"><strong><span style="color: #ff0000;">The potential for name collision with proposed new gTLDs is substantial.</span> </strong>Based
on the data analyzed for this study, strings that have been proposed as
new gTLDs appeared in 3% of the requests received at the root servers
in 2013. Among all syntactically valid TLD labels (existing and
proposed) in requests to the root in 2013, the proposed TLD string home
ranked 4th, and the proposed corp ranked 21st. DNS traffic to the root
for these and other proposed TLDs already exceeds that for
well-established and heavily-used existing TLDs.</p><p style="padding-left: 30px;"><strong>Several options for mitigating the risks associated with name collision have been identified. </strong>For
most of the proposed TLDs, collaboration among ICANN, the new gTLD
applicant, and potentially affected third parties in the application of
one or more of these risk mitigation techniques is likely to
substantially reduce the risk of delegation.</p><p style="padding-left: 30px;"><strong>The potential for name collision
with proposed new gTLDs often arises from well- established policies and
practices in private network environments.</strong> <span style="color: #ff0000;">Many
of these were widely adopted industry practices long before ICANN
decided to expand the public DNS root; the problem cannot be reduced to
“people should have known better.”</span></p><p style="padding-left: 30px;"><strong>The delegation of almost any of the applied-for strings as a new TLD label would carry some risk of collision.</strong>
Of the 1,409 distinct applied-for strings, only 64 never appear in the
TLD position in the request stream captured during the 2012 “Day in the
Life of the Internet” (DITL) measurement exercise, and only 18 never
appear in any position. In the 2013 DITL stream, 42 never appear in the
TLD position, and 14 never appear in any position.</p><p style="padding-left: 30px;"><strong>The risk associated with
delegating a new TLD label arises from the potentially harmful
consequences of name collision, not the name collision itself.</strong> This study was concerned primarily with the measurement and analysis of the potential for name collision at the DNS root. <span style="color: #ff0000;">An
additional qualitative analysis of the harms that might ensue from
those collisions would be necessary to definitively establish the risk
of delegating any particular string as a new TLD label</span><strong><span style="color: #ff0000;"><span style="color: #ff00ff;">,</span> <span style="text-decoration: underline;">and in some cases the consequential harm might be apparent only after a new TLD label had been delegated</span>. </span></strong></p><p style="padding-left: 30px;"><strong>The rank and occurrence of applied-for strings in the root query stream follow a power- law distribution.</strong>
A relatively small number of proposed TLD strings account for a
relatively large fraction of all syntactically valid non-delegated
labels observed in the TLD position in queries to the root.</p><p style="padding-left: 30px;"><strong>The sources of queries for proposed TLD strings also follow a power-law distribution.</strong>
For most of the most-queried proposed TLD strings, a relatively small
number of distinct sources (as identified by IP address prefixes)
account for a relatively large fraction of all queries.<br>
A wide variety of labels appear at the second level in queries when a
proposed TLD string is in the TLD position. For most of the most-queried
proposed TLD strings, the number of different second-level labels is
very large, and does not appear to follow any commonly recognized
empirical distribution.</p><p style="padding-left: 30px;"><strong>Name collision in general
threatens the assumption that an identifier containing a DNS domain name
will always point to the same thing. <span style="color: #ff0000;">Trust
in the DNS (and therefore the Internet as a whole) may erode if
Internet users too often get name-resolution results that don’t relate
to the semantic domain they think they are using. This risk is
associated not with the collision of specific names, but with the
prevalence of name collision as a phenomenon of the Internet experience.</span></strong></p><p style="padding-left: 30px;"><span style="color: #ff0000;"><strong>The
opportunity for X.509 public key certificates to be erroneously
accepted as valid is an especially troubling consequence of name
collision.</strong> <span style="color: #000000;">An application
intended to operate securely in a private context with an entity
authenticated by a certificate issued by a widely trusted public
Certification Authority (CA) could also operate in an apparently secure
manner with another equivalently named entity in the public context if
the corresponding TLD were delegated at the public DNS root and some
party registered an equivalent name and obtained a certificate from a
widely trusted CA. The ability to specify wildcard DNS names in
certificates potentially amplifies this risk.</span></span></p><p style="padding-left: 30px;"><strong>The designation of any
applied-for string as “high risk” or “low risk” with respect to
delegation as a new gTLD depends on both policy and analysis.</strong>
This study provides quantitative data and analysis that demonstrate the
likelihood of name collision for each of the applied-for strings in the
current new gTLD application round and qualitative assessments of some
of the potential consequences. Whether or not a particular string
represents a delegation risk that is “high” or “low” depends on policy
decisions that relate those data and assessments to the values and
priorities of ICANN and its community; and as Internet behavior and
practice change over time, a string that is “high risk” today may be
“low risk” next year (or vice versa).</p><p style="padding-left: 30px;"><strong>For a broad range of potential
policy decisions, a cluster of proposed TLDs at either end of the
delegation risk spectrum are likely to be recognizable as “high risk”
and “low risk.”</strong> At the high end, the cluster includes <span style="color: #ff0000;">the proposed TLDs that occur with at least order-of-magnitude greater frequency than any others</span><strong><span style="color: #ff0000;"> (corp and home)</span></strong> <span style="color: #ff0000;">and those that occur most frequently in internal X.509 public key certificates <strong>(mail and exchange in addition to corp)</strong></span><strong>.</strong>
At the low end, the cluster includes all of the proposed TLDs that
appear in queries to the root with lower frequency than the
least-frequently queried existing TLD; using 2013 data, that would
include 1114 of the 1395 proposed TLDs.</p><p>And here is their list of risk-mitigation options.</p><p style="padding-left: 30px;"><strong>9 Name collision risk mitigation</strong></p><p style="padding-left: 30px;">ICANN and its partners in the Internet
community have a number of options available to mitigate the risks
associated with name collision in the DNS. This section describes each
option; its advantages and disadvantages; and the residual risk that
would remain after it had been successfully implemented.</p><p style="padding-left: 30px;">The viability, applicability, and cost of
different risk mitigation options are important considerations in the
policy decision to delegate or not delegate a particular string. For
example, a string that is considered to be “high risk” because risk
assessment finds that it scores high on occurrence frequency or severity
of consequences (or both), but for which a very simple low-cost
mitigation option is available, may be less “risky” with respect to the
delegation policy decision than a string that scores lower during risk
assessment but for which mitigation would be difficult or impossible.</p><p style="padding-left: 30px;">It is important to note that in addition
to these strategies for risk mitigation, there is a null option to “do
nothing”—to make no attempt to mitigate the risks associated with name
collision, and let the consequences accrue when and where they will. As a
policy decision, this approach could reasonably be applied, for
example, to strings in the “low risk” category and to some or all of the
strings in the “uncalculated risk” category.</p><p style="padding-left: 30px;">It is also important to note that this
study and report are concerned primarily with risks to the Internet and
its users associated with the occurrence and consequences of name
collision—not risks to ICANN itself associated with new TLD delegation
or risk mitigation policy decisions.</p><p style="padding-left: 30px;"><strong>9.1 Just say no</strong></p><p style="padding-left: 30px;">An obvious solution to the potential
collision of a new gTLD label with an existing string is to simply not
delegate that label, and formally proscribe its future delegation—e.g.,
by updating [15] to permanently reserve the string, or via the procedure
described in [9] or [16]. This approach has been suggested for the “top
10” strings by [ ], and many efforts have been made over the past few
years to add to the list of formally reserved strings [15] other
non-delegated strings that have been observed in widespread use [1] [9]
[10] [16].<br>
A literal “top 10” approach to this mitigation strategy would be
indefensibly arbitrary (the study data provide no answer to the obvious
question “why 10?”), but a policy decision could set the threshold at a
level that could be defended by the rank and occurrence data provided by
this study combined with a subjective assessment of ICANN’s and the
community’s tolerance for uncertainty.</p><p style="padding-left: 30px;">9.1.1 Advantages<br>
A permanently reserved string cannot be delegated as a TLD label, and
therefore cannot collide with any other use of the same string in other
contexts. A permanently reserved string could also be recommended for
use in private semantic domains.</p><p style="padding-left: 30px;">9.1.2 Disadvantages<br>
There is no disadvantage for the Internet or its users. The
disadvantages to current or future applicants for permanently proscribed
strings are obvious. Because the “top N” set membership inclusion
criteria will inevitably change over time, this mitigation strategy
would be effective beyond the current new gTLD application round only if
those criteria (and the resulting set membership) were periodically
re-evaluated.</p><p style="padding-left: 30px;">9.1.3 Residual risk<br>
This mitigation strategy leaves no residual risk to the Internet or its users.</p><p style="padding-left: 30px;"><strong>9.2 Further study</strong></p><p style="padding-left: 30px;">For a string in the “non-customary risk”
or “calculated risk” category, further study might lead to a
determination that the “severity of consequences” factor in the risk
assessment formula is small enough to ensure that the product of
occurrence and severity is also small.</p><p style="padding-left: 30px;">9.2.1 Advantages<br>
Further study might shift a string from the “uncalculated risk” to the
“calculated risk” category by providing information about the magnitude
of the “severity of consequences” factor. It might also reduce the
uncertainty constant in the risk assessment formula, facilitating a
policy decision with respect to delegation of the string as a new TLD.</p><p style="padding-left: 30px;">9.2.2 Disadvantages<br>
Further study obviously involves a delay that may or may not be
agreeable to applicants, and it may also require access to data that are
not (or not readily) available. Depending on the way in which a
resolution request arrives at the root, it may be difficult or
impossible to determine the original source; and even if the source can
be discovered, it might be difficult or impossible (because of lack of
cooperation or understanding at the source) to determine precisely why a
particular request was sent to the root.</p><p style="padding-left: 30px;">The “further study” option also demands a
termination condition: “at what point, after how much study, will it be
possible for ICANN to make a final decision about this string?”</p><p style="padding-left: 30px;">9.2.3 Residual risk<br>
Unless further study concludes that the “severity of consequences” factor is zero, some risk will remain.</p><p style="padding-left: 30px;"><strong>9.3 Wait until everyone has left the room</strong></p><p style="padding-left: 30px;">At least in principle, some uses of names
that collide with proposed TLD strings could be eliminated: either
phased out in favor of alternatives or abandoned entirely. For example,
hardware and software systems that ship pre-configured to advertise
local default domains such as home could be upgraded to behave
otherwise. In these cases, a temporary moratorium on delegation, to
allow time for vendors and users to abandon the conflicting use or to
migrate to an alternative, might be a reasonable alternative to the
permanent “just say no.” Similarly, a delay of 120 days54 before
activating a new gTLD delegation could mitigate the risk associated with
internal name certificates described in Sections 6.2 and 7.2.</p><p style="padding-left: 30px;">9.3.1 Advantages<br>
A temporary injunction that delays the delegation of a string pending
evacuation of users from the “danger zone” would be less restrictive
than a permanent ban.</p><p style="padding-left: 30px;">9.3.2 Disadvantages<br>
Anyone familiar with commercial software and hardware knows that
migrating even a relatively small user base from one version of the same
system to another—much less from one system to a different system—is
almost never as straightforward in practice as it seems to be in
principle. Legacy systems may not be upgradable even in principle, and
consumer-grade devices in particular are highly unlikely to upgrade
unless forced by a commercial vendor to do so. The time scales are
likely to be years—potentially decades—rather than months.</p><p style="padding-left: 30px;">Embracing “wait until...” as a mitigation
strategy would therefore require policy decisions with respect to the
degree of evacuation that would be accepted as functionally equivalent
to “everyone” and a mechanism for coordinating the evacuation among the
many different agents (vendors, users, industry consortia, etc.) who
would have to cooperate in order for it to succeed.</p><p style="padding-left: 30px;">9.3.3 Residual risk<br>
Because no evacuation could ever be complete, the risks associated with
name collision would remain for whatever fraction of the affected
population would not or could not participate in it.</p><p style="padding-left: 30px;"><strong>9.4 Look before you leap</strong><br>
Verisign [4] and others (including [8]) have recommended that before a
new TLD is permanently delegated to an applicant, it undergo a period of
“live test” during which it is added to the root zone file with a short
TTL (so that it can be flushed out quickly if something goes wrong)
while a monitoring system watches for impacts on Internet security or
stability.</p><p style="padding-left: 30px;">9.4.1 Advantages<br>
A “trial run” in which a newly-delegated TLD is closely monitored for
negative effects and quickly withdrawn if any appear could provide a
level of confidence in the safety of a new delegation comparable to that
which is achieved by other product-safety testing regimes, such as
pharmaceutical and medical-device trials or probationary-period
licensing of newly trained skilled craftsmen.</p><p style="padding-left: 30px;">9.4.2 Disadvantages<br>
The practical barriers to instrumenting the global Internet in such a
way as to effectively perform the necessary monitoring may be
insurmountable. Not least among these is the issue of trust and
liability—for example, would the operator of a “live test” be expected
to protect Internet users from harm during the test, or be responsible
for damages that might result from running the test?</p><p style="padding-left: 30px;">9.4.3 Residual risk<br>
No “trial run” (particularly one of limited duration) could perfectly
simulate the dynamics of a fully-delegated TLD and its registry, so some
risk would remain even after some period of running a live test.</p><p style="padding-left: 30px;"><strong>9.5 Notify affected parties<br>
</strong>For some proposed TLDs in the current round, it may be possible
to identify the parties most likely to be affected by name collision,
and to notify them before the proposed TLD is delegated as a new gTLD.</p><p style="padding-left: 30px;">9.5.1 Advantages<br>
Prior notice of the impending delegation of a new gTLD that might
collide with the existing use of an identical name string could enable
affected parties to either change their existing uses or take other
steps to prepare for potential consequences.</p><p style="padding-left: 30px;">9.5.2 Disadvantages<br>
Notification increases awareness, but does not directly mitigate any
potential consequence of name collision other than surprise. For many
proposed TLDs it might be difficult or impossible to determine which
parties could be affected by name collision. Because affected parties
might or might not understand the potential risks and consequences of
name collision and how to manage them, either in general or with respect
to their own existing uses, notification might be ineffective without
substantial concomitant technical and educational assistance.</p><p style="padding-left: 30px;">9.5.3 Residual risk<br>
In most cases at least some potentially affected parties will not be
recognized and notified; and those that are recognized and notified may
or may not be able to effectively prepare for the effects of name
collision on their existing uses, with or without assistance.</p><p>Here are some of the tasty bits from a <a href="http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf">risk-mitigation proposal issued by ICANN staff </a>several days later (5-August, 2013).</p><p><strong>[ICANN Staff] PROPOSAL TO MITIGATE RISK</strong></p><p style="padding-left: 30px;"><strong>LOW-RISK</strong></p><p style="padding-left: 30px;">The Study establishes a low-risk profile
for 80% of the strings. ICANN proposes to move forward with its
established processes and procedures with delegating strings in this
category (e.g., resolving objections, addressing GAC advice, etc.) after
implementing two measures in an effort to mitigate the residual
namespace collision risks.</p><p style="padding-left: 30px;">First, registry operators will implement a
period of no less than 120 days from the date that a registry agreement
is signed before it may activate any names under the TLD in the DNS1.
This measure will help mitigate the risks related to the internal name
certificates issue as described in the Study report and SSAC Advisory on
Internal Name Certificates. Registry operators, if they wish, may
allocate names during this period, i.e., accept registrations, but they
will not activate them in DNS. If a registry operator were to allocate
names during this 120-day period, it would have to clearly inform the
registrants about the impossibility to activate names until the period
ends.</p><p style="padding-left: 30px;">Second, once a TLD is first delegated
within the public DNS root to name servers designated by the registry
operator, the registry operator will not activate any names under the
TLD in the DNS for a period of no less than 30 days. <span style="color: #ff0000;"><strong>During
this 30-day period, the registry operator will notify the point of
contacts of the IP addresses that issue DNS requests for an un-delegated
TLD or names under it.</strong></span> The minimum set of requirements
for the notification is described in Appendix A of this paper. This
measure will help mitigate the namespace collision issues in general.
Note that both no-activate- name periods can overlap.</p><p style="padding-left: 30px;">The TLD name servers may see DNS queries
for an un-delegated name from recursive resolvers – for example, a
resolver operated by a subscriber’s ISP or hosting provider, a resolver
operated by or for a private (e.g., corporate) network, or a global
public name resolution service. <span style="color: #ff0000;"><strong>These
queries will not include the IP address of the original requesting
host, i.e., the source IP address that will be visible to the TLD is the
source address of the recursive resolver. In the event that the TLD
operator sees a request for a non-delegated name, it must request the
assistance of these recursive resolver operators in the notification
process as described in Appendix A.</strong></span></p><p style="padding-left: 30px;"><strong>HIGH-RISK</strong></p><p style="padding-left: 30px;">ICANN considers that the Study presents
sufficient evidence to classify home and corp as high-risk strings.
Given the risk level presented by these strings, ICANN proposes not to
delegate either one until such time that an applicant can demonstrate
that its proposed string should be classified as low risk based on the
criteria described above. An applicant for one of these strings would
have the option to withdraw its application, or work towards resolving
the issues that led to its categorization as high risk (i.e., those
described in section 7 of the Study report). An applicant for a
high-risk string can provide evidence of the results from the steps
taken to mitigate the name collision risks to an acceptable level. ICANN
may seek independent confirmation of the results before allowing
delegation of such string.</p><p style="padding-left: 30px;"><strong>UNCALCULATED-RISK</strong></p><p style="padding-left: 30px;">For the remaining 20% of the strings that
do not fall into the low or high-risk categories, further study is
needed to better assess the risk and understand what mitigation measures
may be needed to allow these strings to move forward. The goal of the
study will be to classify the strings as either low or high-risk using
more data and tests than those currently available. While this study is
being conducted, ICANN would not allow delegation of the strings in this
category. ICANN expects the further study to take between three and six
months. At the same time, an applicant for these strings can work
towards resolving the issues that prevented their proposed string from
being categorized as low risk (e.g., those described in section 7 of the
Study report). An applicant can provide evidence of the results from
the steps taken to mitigate the name collision risks to an acceptable
level. ICANN may seek independent confirmation of the results before
allowing delegation of such string. If and when a string from this
category has been reclassified as low-risk, it can proceed as described
above for the low-risk category strings.</p><p style="padding-left: 30px;"><strong>CONCLUSION</strong></p><p style="padding-left: 30px;">ICANN is fully committed to the
delegation of new gTLDs in a secure and stable manner. As with most
things on the Internet, it is not possible to eliminate risk entirely.
Nevertheless, ICANN would only proceed to delegate a new gTLD when the
risk profile of such string had been mitigated to an acceptable level.
We appreciate the community's involvement in the process and look
forward to further collaboration on the remaining work.</p><p style="padding-left: 30px;"><strong>APPENDIX A – NOTIFICATION REQUIREMENTS</strong></p><p style="padding-left: 30px;"><strong><span style="color: #ff0000;"><span style="text-decoration: underline;">Registry operator</span>
will notify the point of contact of each IP address block that issue
any type of DNS requests (the Requestors) for names under the TLD or its
apex.</span></strong> The point of contact(s) will be derived from the
respective Regional Internet Registry (RIR) database. Registry operator
will offer customer support for the Requestors or their clients (origin
of the queries) in, at least, the same languages and mechanisms the
registry plans to offer customer support for registry services. Registry
operator will avoid sending unnecessary duplicate notifications (e.g.
one notification per point of contact).</p><p style="padding-left: 30px;">The notification should be sent, at
least, over email and must include, at least the following elements: 1)
the TLD string; 2) why the IP address holder is receiving this email; 3)
the potential problems the Requestor or its clients could encounter
(e.g., those described in section 6 of the Study report); 4) the date
when the gTLD signed the registry agreement with ICANN, and the date of
gTLD delegation; 5) when the domain names under the gTLD will first
become active in DNS; 6) multiple points of contact (e.g. email address,
phone number) should people have questions; 7) will be in English and
may be in other languages the point of contact is presumed to know; 8)
ask the Requestors to pass the notification to their clients in case the
Requestors are not the origin of the queries, e.g., if they are
providers of DNS resolution services; 9) a sample of timestamps of DNS
request in UTC to help identify the origin of queries; 10) email
digitally signed with valid S/MIME certificate from well- known public
CA.</p><p>It's that last appendix, where people are going to get notified, that
really caught my eye. I can imagine a day when an ISP is going to get
notifications from all kinds of different registry operators listing the
IP addresses of their customer-facing recursive DNS servers. The
notification will be that their customers are generating this kind of
error traffic -- but leaves the puzzle of figuring out <span style="text-decoration: underline;"><strong>which</strong></span>
customer up to the ISP. Presumably this leaves the ISPs to comb
through DNS logs to ferret out which customer it actually was, carry the
bad news to the customer, and presumably deal with the outraged
fallout. In other cases these notifications will go directly to
corporate network operators with the same result. In either case,
ponder the implications of a 30 lead-time to fix these things. Maybe
easy. Maybe not.</p><p><strong>What's next? Where do we go from here?</strong></p><p>For me, "learning more" and "spreading the word" are the next steps.
People on all sides of the argument are weighing in, but as InterIsle
points out, there is a lot of analysis that should be done. They were
able to identify the number of queries, the new-TLDs that were queried
and the scope of IP addresses of where queries came from. What they
point out we don't (and need to) know is the impact of those. How bad
would the breakdowns be? Opinions are loudly stated, but facts are
scarce.</p><p>If you want to learn more, the best place to get started is probably
ICANN's "Public Comment" page on this issue. You'll have some reading
to do, but right now (until 17-September, 2013) you have the opportunity
to submit comments. The more of you that do that the better. The
spin-doctors on all sides are hard at work -- it's very difficult to
find unbiased information. There aren't very many comments as I write
this in mid-August, but they should make interesting reading as they
come in -- and you can read them too.</p><p style="padding-left: 30px;">Click <a title="ICANN name-collision public comment page" href="http://www.icann.org/en/news/public-comment/name-collision-05aug13-en.htm">HERE</a> for the ICANN public-comment page</p><p>That's more than enough for one blog post. Sorry this "little bit
more detail" section got so long. There's plenty more if you want to
dig further.</p><p><strong>DISCLAIMER</strong>: Be aware that almost everybody in this debate is conflicted in one way or another (including me - <a href="https://community.icann.org/display/gnsosoi/Mikey+O%27Connor+SOI">here's a link</a>
to my "Statement of Interest" on the ICANN site). I participate in
ICANN as the representative of a regional internet exchange point (<a href="http://micemn.net/">MICE</a>) and also as the owner of a gaggle of really generic .COM domains (click <a href="http://www.haven2.com/index.php/domains">HERE</a>
for that story). I haven't got a clue what the impact of new gTLDs
will be on my domains. I also don't know what the impact will be on
ISPs and corporate network operators but I am very uneasy right now. I
may write some more opinionated posts about that unease, once I
understand better what's going on.</p></div><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</span>
</div>
<br></body></html>