Neustar views the preservation of stability and security of the domain name system (“DNS”) to be the “prime directive” of the Internet Corporation for Assigned Names and Numbers (“ICANN”) and all responsible participants in the DNS ecosystem. Accordingly, we have welcomed the community’s focus on stability and security issues in connection with the launch of new generic top-level domains (“gTLDs”).
In particular, we welcomed the report undertaken by Interisle Consulting Group, LLC entitled Name Collision in the DNS (the “Interisle Report”), which provides important insight into the possibility of a domain name collision. As the report itself acknowledges, however, query volume alone is not an adequate or appropriate basis for evaluating the risk of harm associated with any such collisions. As Interisle notes, the risk that ICANN must address and mitigate is the “potentially harmful consequences of name collision, and not the name collision itself.”
ICANN’s mitigation strategy rests entirely on the possibility of collision, not the consequences. As a result, ICANN’s plan, in response to the Interisle Report, would relegate many demonstrably low-risk gTLDs to the nether world of “uncalculated risk” and impose further unwarranted delay in the launch of those gTLDs. ICANN’s approach goes beyond simple prudence; it unnecessarily slows down the process of rolling out gTLDs, which enterprises have been working on for years. Prudence and due deliberation are always called for in a system upgrade of this magnitude, but ICANN’s “uncalculated risk” category throws too many clearly low-risk gTLDs into a nightmare of uncertainty, and needs to be fixed.
Moreover, we disagree with the need for delay to conduct additional research in order to quantify the risk associated with the introduction of the vast majority of proposed new gTLDs. Rather, we believe that ICANN already has all the data and research necessary to calculate the risk and develop mitigation strategies that are carefully tailored to the specific risk associated with each TLD.
In this paper we propose an alternative, comprehensive risk evaluation methodology, based on an analysis of existing information available on four key variables including: (i) TLD query volume; (ii) query source IP address volume; (iii) queried second- level domain volume; and (iv) volume of SSL certificates.
Using these four inputs, one can calculate the relative risk for every applied-for TLD and compare that with known information about the many new TLDs launched without incident over the past decade. This analysis eliminates the “uncalculated risk” classification in the Interisle Report and the need for further research or qualitative analysis. Based on our analysis, Neustar identified only 3 TLDs that appear to merit mitigation strategies beyond the approach required for all other TLDs.
Finally, we offer a mitigation approach that reflects actual risk, is narrowly tailored to the type of risk involved, and in most cases eliminates the need for additional delay.
The Interisle Consulting Group, LLC (“Interisle”) studied and reported on the likelihood and potential consequences of collisions between new public gTLD labels and existing private uses of the same strings. The study, Name Collisions in the DNS, was “concerned primarily with the measurement and analysis of the potential for name collision at the DNS root,” rather than the risk associated with such collisions. As Interisle noted, however, it is the potentially harmful consequences of a collision and “not the name collision itself” that determines the risk arising from the introduction of any new gTLD string1. That was not Interisle’s focus: rather, the “probability of the occurrence” was the study’s “principle focus.”2
The volume of queries for any particular string may be a reasonable measure of the possibility of collision. As Interisle noted, however, the risk of harm associated with such potential collisions depends upon a variety of other factors including both additional data points and policy.3 Based on its quantitative analysis of the incidence of name collisions, Interisle designated a small set of applied-for strings as “high risk.” Similarly based exclusively on query volume, Interisle identified a number of strings as “low risk.” Interisle concluded, however, that nearly twenty percent (20%) of the applied-for gTLD strings fell into the “uncalculated” category, presumably because Interisle concluded that using query volume as a proxy for risk of harm was inadequate in these cases.
ICANN’s proposed mitigation plan, however, does just that—equating the volume of inquiries to the level of associated risk. Moreover, while both Interisle and the community have identified a range of mitigation strategies, ICANN’s mitigation approach is based on an entirely different factor—the amount of time requested by certificate authorities to address potential collisions with internal name certificates. While the Interisle study provides a valuable foundation for the conversation now underway in the community, it does not support ICANN’s proposal to impose a 4-month hold on second-level registrations on all strings— including those for which certificates have not been issued—and its use of an arbitrary 80/20 rule to impose a further delay of unknown duration for several hundred strings.
Query volume alone is not an appropriate measure of risk. We believe, however, that existing data about the number of query sources, the appearance of strings as second-level domains (SLDs), and the existence of corresponding X.509 public key certificates can be combined with query volume data to undertake a more comprehensive evaluation of the relative “risk of harm” associated with collisions for virtually all of the applied-for strings.4 A more nuanced risk assessment methodology also facilitates more focused and effective mitigation efforts and, in turn, the timely launch of new gTLDs.
From Query Volume to Risk Assessment
To calculate risk, one must understand both the magnitude of potential harm and the level of exposure to the chance of injury or loss.5
The research and analysis provided in the Interisle Report provides a solid foundation for understanding the potential for DNS collisions during the launch of new TLDs. It also reflects the community’s commitment to ensuring that the launch of new gTLDs does not compromise the stability and security of the DNS. Notably, there have been no such studies in advance of introducing new TLDs in the last 12 years—and fortunately there have been no notable collisions with the launch of new TLDs during that time. As Paul Mockapetris, “father of the DNS” states, “There is an unprecedented level of caution.”
Although the Interisle Report briefly describes some of the theoretical consequences of a name collision, it does not attempt to quantify such risk. Only 3 pages of the 178-page report address the potential consequences resulting from name collisions; they do not address the likelihood that such consequences would occur or the ramification of such collisions if they indeed did occur. The report outlines some of the tools that can be used to classify risk, but it does not implement them. It collects much of the data that it would need to measure impact, but then does not apply them to the risk formula. It proposes what the risk gradient chart would look like, but it does not actually complete it.
That is not an oversight. The Interisle research had a very clear purpose: to identify the possibility of collision. Said another way, the report commissioned by ICANN was intended to examine whether it was theoretically possible that a domain name collision could occur in the new gTLD space, not to assess the impact of such a collision on security and stability. ICANN itself states:
The study was to consider whether name collisions might occur between applied-for new gTLD strings and non-delegated TLDs that may be in use in private namespaces. The study was also to review the possibility of name collisions arising from the use of X.509 digital certificates.6
The Interisle Report acknowledges this as well and explicitly notes that the possibility of a collision and the actual likelihood of risk of exposing the larger Internet to some danger are two separate and distinct items:
This study was concerned primarily with the measurement and analysis of the potential for name collision at the DNS root . . . the risk associated with delegating a new TLD label arises from the potentially harmful consequences of name collision, not the name collision itself.7
This paper takes the Interisle Report to the next level using additional variables that quantify the “severity of consequences” component of the risk equation and providing a holistic understanding of risk. We use many of the same elements that Interisle recommends as a proxy to understand the severity of consequences. We build upon the probability of collision research that is so thoroughly detailed and then supplement that research with a quantitative analysis of the consequences of a collision. The analysis provides an analytical methodology to both classify risk and then propose appropriate measures to mitigate any harmful consequences.
Query Volume is Not a Proxy for Risk of Harm
Several industry and thought leaders have noted that the exclusive use of query volume to non-existing domains (NXD) to assess risk of harm is flawed. Both Neustar and the New TLD Applicant Group (NTAG)—which includes the world’s leading technology innovators as its members—pointed this out in the preliminary comment period.8
While Interisle might be right that fewer queries mean less risk, its assumption that a “reasonable threshold for low risk” could be established by reference to the number of queries for existing TLDs that are empty (meaning that their zones contain only the necessary DNS meta-data) is overly simplistic. Likewise, VeriSign confirms that “there is evidence that suggests that the traffic volume is not the only indicator of risk,” when proposing their own risk profile model.9
Suffice it to say that domain name collisions happen every day. A typo in system code or a simple “fat finger” will often land the inquiring party, the one requesting the domain name, in a location that they were not expecting. These collisions have existed for years and will occur far into the future—whether or not there are new gTLDs. The resilience of the DNS in this respect is a relevant factor in evaluating the risk of harm from name collision: despite near constant name collisions, we are unaware of any such incident that threatened the security and stability of the Internet.10
Verisign, for example, has pointed to only two incidents of collision, neither of which affected the security and stability of the Internet, both of which occurred in the .COM top-level domain.11
The fact that collisions have occurred in .COM is not a surprise, given the number of .COM domain names and associated DNS traffic queries. In fact, the likelihood of a collision in the .COM name space is exponentially greater than in any one of the new gTLDs. Using data gathered from Neustar’s UltraDNS Advantage platform, we compared queries for undefined name volumes for established and proposed TLDs during the 2013 DITL time period.
As the graph below illustrates, .COM experienced over 30,000 times more queries than did the string .NYC, 170,000 more queries than the string .SECURE, and 1.3 million times more queries than .CLUB. Despite the staggering difference in the volume of such queries, ICANN has relegated .NYC, .SECURE, and .CLUB to the category of “uncalculated risk” and put them on indefinite hold for further research and analysis. Meanwhile, .COM, with 442 million opportunities for domain name collisions, continues to register new domain names, respond to queries, and operate as normal.
|TLD||Queries for Undefined Names||￼Multiple of .COM Query Volume|
So why have we not heard the chorus of advocates proposing to cease new registration of .COM domain names while the community investigates risk? There two reasons:
- Volume of queries for undefined names is not a good single measure of the risk resulting from a DNS collision; and
- The Internet is resilient and able to support innovation through the introduction of new gTLDs.
Existing Data Supports Risk Profile Scoring
Both Interisle and ICANN call for putting the launch of hundreds of new gTLDs on hold pending further risk assessment and analysis. Based on our analysis, that is unnecessary.
Both the data provided by the DNS Operations Analysis and Research Center (OARC) as well as Interisle’s Report can be used to evaluate risk and develop tailored mitigation strategies. This research has been supplemented by the community, which in recent weeks has provided significant funding for new OARC equipment and undertaken self-funded analysis. Data scientists, policy experts, and security analysts have invested countless hours to conduct an extensive analysis of this issue.12
A More Refined Risk Profile Methodology
Neustar is in the business of assessing risk. As the leading provider of information analytics, we help the largest retailers, ecommerce providers, financial institutions and government agencies identify, assess and mitigate risk every day. Understanding risk is what we do.
Accurately predicting risk is always challenging, but the fundamentals of risk assessment are simple. There are two key elements:
- The likelihood of an event occurring
- The impact of that event on the system
While the Interisle Report identified both elements, it only quantified the first. When the data is on hand, as it is here, it is possible to quantify the second element and develop and apply a methodology to derive a risk score.
Risk Score Inputs
A comprehensive Risk Assessment classification requires a compilation of risk factors that can assess, weigh and measure both the likelihood and impact of an event. Neither the Interisle Report nor the ICANN mitigation plan considered impact. Digicert, one of the world’s leading certificate authorities, puts it best, stating that ICANN’s “overly cautious approach is a result of purely considering the number of potential gTLD collisions without factoring in the other information provided in the Interisle report. We believe that when the additional data on certificates, SLD information, and total number of domains are considered, only a handful of strings truly need further consideration.”13
Application of Neustar’s risk profile methodology, as seen later, fully supports this belief. Our risk assessment module considers four distinct inputs:
- NXD query volume (l1)
- Diversity of NXD request sources IP addresses (r1)
- Diversity of SLDs in NXD requests (r2)
- SSL certificates issued (r3)
For each of the vectors above, we provide both the raw data and also a relative risk score associated with that data. Visualization of the data for these vectors supports Digicert’s contention—only a handful of new gTLDs merit further analysis.
The following sections provide some detail on the 4 variables along with illustrations that help visualize the data. We also provide a risk scoring methodology in the summary findings.
NXD Query Volume Score (l1)
Neustar first used the relative NXD query volume of applied-for strings to calculate a Query Volume Score.
Rationale: NXD query volume, as the Interisle Report concluded, appears to provide an adequate proxy to determine the likelihood of the occurrence of a domain name collision. For purposes of the risk profile, the domain name collision is the risk event. Although DNS caching and other factors may obfuscate some of our ability to see every DNS query at the root, the NXD query volume provides the best estimation for the likelihood of collision.
Raw Data: To perform this analysis, Neustar and other OARC members reviewed data from the 2013 DITL dataset and produced accurate counts of query volumes. These counts were in line with the Interisle Report, with minor variations due to increased accuracy of tools employed.
The raw query counts reflect the dramatic difference between a very few TLDs and the remaining proposed TLDs. As discussed above, except for the top TLDs, these numbers compare favorably to previously launched TLDS14. Consistent with the Interisle Report, the top TLDs show a significant skewing of results toward .HOME and .CORP, highlighted by the graph to the right.
Risk Score Methodology: The NXD Query Volume Score is then calculated using existing query volumes at the root servers, as shown in the DITL 2013 dataset. To calculate the relative risk score for each TLD, we divided the TLD’s query total during the sample period by the highest query volume of the proposed TLDs. The highest query volume proposed for TLD was .HOME, with a query count of 829K in 2013. The resulting value is multiplied by 100. The results from all of these scores are listed later in the Total Risk Score.
Query Source Address Diversity Score (r1)
Next, Neustar used information about source query diversity to calculate a Query Source Address Diversity Score.
Rationale: Query Source Address Diversity measures the number of different source addresses that are querying for a TLD. This provides the first of three indicators of the impact of the domain name collision. Measuring the relative number of source addresses and not the query volume of those source addresses eliminates a ratification inflation of the degree of risk driven by queries from the same source.
For reference, the number of source addresses for .SX, a TLD delegated in December 2011, exceeds 130,000. The number of source addresses for .SJ, the reference “cut-off” line for determining low or uncalculated risk in ICANN’s mitigation recommendation, is over 5,500.
Raw Data: Analyzing the query source addresses, only a few TLDs have source address volumes of any significance. In fact, not one of the applied-for TLDs have more source addresses than the delegated ccTLD, .SX, and 90% of the (1257) have fewer source addresses than .SJ.
Risk Score Methodology: The Query Source Address Diversity Score was calculated using a comparison of unique source addresses in query volumes for a specific proposed TLD, as compared to the proposed TLD with the highest number of unique source addresses. The count of unique source addresses is calculated by identifying all source addresses for queries and their respective query counts. The top source addresses are then selected, accounting for a combined 98% of query volume. This approach was taken to identify primary querying resolvers. Ninety-eight percent was selected as a conservative value, to ensure most traffic was used in this count. To calculate the Query Source Address Diversity Score, this count is divided by the number of top 98% source addresses of the most diverse TLD, .MAIL with 66,006 unique source network addresses in the 2013 DITL data set, and the resulting value is multiplied by 100.
Query Second-Level Domain (SLD) Diversity Score (r2)
Next, Neustar scored applied-for strings based on the relative number of second-level domains to which queries were directed.
Rationale: The Query SLD Diversity Score is an indicator of how many second-level domains within each new top-level domain are being queried. This data assists in quantifying the consequences of the collision. In some instances, a very few number of second-level domains account for the majority of the queries for that TLD. As an example, research for .NYC at the recursive DNS level revealed that 2 second- level domains accounted for 98% of the total queries for the TLD. Decoupling the number of second-level domain inquiries from queries at the root level provides a more accurate picture of the risk.
Raw Data: To support this analysis, Neustar and other OARC members reviewed data from the 2013 DITL dataset and for each TLD produced counts of unique SLDs queried. Once again, the raw data illustrates a sharp decline in risk associated with this vector after the first few names.
Risk Score Methodology: The Query SLD Diversity Score was calculated by comparing the unique second-level domains in query volumes for a specific proposed TLD to the proposed TLD with the highest number of these unique SLDs. The count of unique SLDs is calculated by first identifying all SLDs in queries and their respective query counts. Then the top SLDs are selected to account for a combined 98% of query volume. This approach was taken to identify SLDs queried with some level of frequency, while avoiding counting SLDs that may have been queried due to users mistyping network addresses. Ninety-eight percent was selected as a conservative value, to ensure most traffic was used in this count. To calculate the Query SLD Diversity Score, this count is divided by the number of top 98% SLDs of the most diverse TLD in the 2013 DITL data set (.HOME with 441 million), and the resulting value is multiplied by 100.
SSL Certificates Issued Score (r3)
Finally, Neustar scored applied-for strings based on the prevalence of corresponding SSL certificates.
Rationale: The final vector plays a significant role in understanding the consequences of a domain name collision. Many of the potential security issues involve the use of a digital certificate. ICANN even specified that the research of the digital certificates be included in the Interisle study. Digital certificates represent the ultimate illustration of end-user or system trust on the Internet. When end users or systems “see” a certificate, it provides assurance that they have in fact reached the place that they intended to reach. It also provides assurance that the user can provide information to that destination in a secure fashion.
The measure of the SSL Certificates Issued is exactly that, a representative count of the number of x.509 certificates issued by certificate authorities for proposed new TLDs.
Raw Data: The raw data for this analysis was gathered from the Interisle Report, Appendix C, offering a 2013 view of issued SSL certificates for proposed TLDs. For proposed TLDs that had fewer than 3 issued certificates, and thus were omitted from the Interisle report, a certificate count of 2 was used, as the most conservative value possible. The data again points to a relatively small number of TLDs accounting for the overwhelming majority of issued SSL certificates for new TLDs. In fact, 2 TLDs (.CORP and .MAIL) account for over 30% of the certificates issued corresponding to the 1300+ applied-for TLDs.
Risk Score Methodology: To calculate the SSL Certificate Issued Score for each TLD, the total of issued certificates corresponding to the TLD’s string was divided by the highest total of issued certificates of the proposed TLDs—.CORP with a total of 2,747 certificates—and this resulting value was multiplied by 100.
Total Risk Score
Neustar then combined the risk vectors qualified above to create a numeric and normalized “Total Risk Score.” We calculated the relative Total Risk Score for each TLD by multiplying the likelihood of the event occurring (l1) by the consequences of the risk15. 7 In formulaic form:
>Raw Risk Score = (l1) *((r1 + r2) *r3))
It is then helpful to put context to that risk score by normalizing the data to provide a comparative view of risk against the other TLDs in the data set. This is achieved by dividing by the maximum risk score and then multiplying by 100. In formulaic form:
>Total Risk Score = Raw Risk Score / Max Risk Score *100
Appendix A lists the Total Risk Score for the first 150 TLDs. The top 30 TLDs are provided below.
What the Results Tell Us
There are two primary takeaways from this risk analysis:
- The risk caused by the occurrence of a domain name collision can be calculated for every proposed TLD from the data that is available today, and
- Only 3 TLDs stand out as having considerably higher risk than other proposed TLDs.
Risk Can Be Calculated
As mentioned earlier in this report, there is more data and analysis on the launch of new TLDs available to policy and decision makers than at any time in the history of the DNS. We have data from the Interisle Report, OARC data, and volumes of input from security and technical experts on domain name collision, enabling leaders to make one of the most informed decisions in the 12-year history of delegating top-level domains.
The risk model provided here provides a methodology for understanding and quantifying the relative risk across the new gTLD applicant pool. Each TLD can be provided a score that enables a comparative view of risk.
3 TLDs Merit Further Consideration
The data points to a dramatic difference between the risk score of the highest ranked TLDs and all other TLDs. The TLD with the highest risk is .CORP, with a risk score of 100. The second highest risk score is .HOME with a score of 62.99. The third highest TLD is .MAIL with a risk score of 2.17. Beyond these 3 TLDs, no single TLD has a score higher than 1.00, with most TLDS reflecting scores so insignificant that the data table needed to show 6 decimal places simply to illustrate that there was a quantifiable figure. One can reasonably assess that TLDs with a risk score lower than 1.00 can be grouped into a “low-risk” category for mitigation purposes. These TLDs represent a risk magnitude less than the top applied-for TLDs, .HOME, .CORP, and .MAIL.
Risk Classification and Mitigation Recommendations
The preceding research and resulting risk profile lends itself to a risk classification system that fits into the model proposed by ICANN. It further quantifies the risk for all proposed TLDs, placing them in one of two risk categories: High Risk Strings and Low Risk Strings.
- High Risk Strings: 3 TLDs (.HOME, .CORP, .MAIL)
- Low Risk Strings: All remaining TLDs
The risk calculation removes the need for an “uncalculated risk” category. The risk profile supports ICANN’s initial finding of both the .HOME and .CORP TLDs as being high risk, but adds .MAIL into this category as well. All other TLDs on both the current low risk and uncalculated risk categories can be classified as low risk.
From this classification, registry operators, ICANN, and the larger Internet community can develop focused and tailored approaches to further reduce both the likelihood and, more importantly, the consequences arising from a domain name collision.
ICANN proposed a series of risk mitigation proposals and requested feedback from the community to help strengthen the effectiveness of those measures. In many cases, the mitigation approach described below provides a more surgical and targeted mitigation recommendation that addresses the specific risk as opposed to a broad sweeping measure that inhibits innovation and growth. The following section outlines ICANN’s mitigation proposals along with Neustar’s recommendations to help improve the effectiveness of those proposals.
High Risk Strings
- ICANN Proposed Mitigation. ICANN proposes to not delegate these strings until such time that the applicant can demonstrate that its proposed string should be classified as Low Risk.
- Neustar Recommendation. Neustar concurs with ICANN’s approach. Based on the risk profile of these TLDs, it is prudent for industry leaders to take a more methodical approach to deploying these TLDs.
Low Risk Strings
- ICANN Proposed Mitigation: 120-day Wait Period. “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 DNS. 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.”
- Commence certification revocation immediately. In collaboration with the CAB Forum, ICANN should work to begin the revocation of certificates for applied-for TLDs immediately. Waiting for contract signing unnecessarily increases the risk associated with potential collisions for reasons that are largely administrative. This would, in turn, provide even more time to help notify and fix systems that are utilizing the unverified domain name certificates without the risk of a domain collision occurring. The 120-day wait period would then commence upon notification of revocation from the CAB Forum or from contract signing, whichever is earlier.
- Apply the 120-day wait period (based on the recommendation above) only to those TLDs with a significant amount of certificates issued as identified by the Interisle report. The 120-day wait period is intended to mitigate the risk associated with corresponding X.509 certificates. It provides a period of time for the revocation to take effect. For TLDs where no corresponding certificates have been issued, this 120-day period serves no purpose.
- Apply the domain name (SLD) activation restriction only to those names that account for the top 80% of NXD query volume. The source of NXD query traffic can vary from a misconfigured system that is querying for the name in the DNS to a simple typo from an individual looking for a website. Those misconfigured systems generate volumes of NXD queries for SLDs. Conversely, the typos make up the long tail of the data, hundreds or thousands of queries for 1 domain name.
- ICANN Proposed Mitigation: 30-day Notification Period. “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. 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.”
- Exclude second level registrations that allow registry operators to operate and promote its TLD from the 30-day hold. It makes little sense to withhold the delegation of all names within a TLD when the evidence does not suggest significant risk of collision. This would allow registry operators to use domain names for the operation and promotion of their TLDs as currently contemplated in the Registry Agreement, Specification 9 (Section 3.2).
- Remove the email notification requirement and replace it with a mandatory notification mechanism, such as a website, with information and instructions. Collecting IP addresses for the purpose of notifying the administrators of those IP addresses has a host of challenges. First, the method is open to gaming in that malicious actors could generate queries for the sole purpose of generating work for the registry operator. Secondly, the administrative contacts listed for those IP addresses are often non-responsive or incorrect. Additionally, finding the actual end-user based on the source IP address is challenging given most corporate and ISP network architectures. Sending emails to those administrators would be ineffective in addressing the problem.
Alternatively, ICANN could mandate that for a period of time, new TLDs must post a standard educational website informing end-users that the TLD has been delegated along with information on how to update their systems to avoid future collision.
The introduction of new gTLDs has been delayed for years by an unending series of “what if” scenarios put forward by groups that never wanted new gTLDs in the first place. Since the new gTLD process began in earnest eight years ago, dozens of new gTLDs and ccTLDs have been launched, including a host of fast-track ccTLDs, .POST, .TEL, .ASIA, and .XXX. None of these launches were accompanied by harmful collision events, even though available data suggests that the potential for collision was relatively higher than it is for the new gTLDs. During that same period, prices for domain names have dramatically decreased, DNS providers have increasingly diversified, domains have become accessible to parts of the world that have never had access to domains before, and there has been increased innovation in the domain name market. Armed with the data we have, it’s time to move forward.
Appendix A-Data Table
- Interisle Report at 2-3.
- Id. at 77.
- Id. at 3.
- To conduct this risk analysis, we leveraged the same OARC data made available to Interisle for its initial research, which has now been made available to new OARC members
- ICANN Mitigation Plan
- Interisle Report at 2-3.
- Commenters noted that Asia, .KP, .AX, .UM and .CW all saw higher query traffic than all 279 of the “Uncalculated Risk” strings; yet the launch of these strings proceeded without any known issues. These string traffic volumes are real world examples of new string delegation and provide a baseline: they used existing traffic, did not cause security and stability impacts, and can serve as a more effective threshold in classifying risk based on query volume.
- Verisign - New gTLD Security, Stability, Resiliency Update; Exploratory Consumer Impact Analysis at 3
- Neustar notes that there was one documented issue within .xxx that involved a name collision (described at http://www.geek.com/news/just- launched-russian-itunes-full-of-porn-due-to-xxx-domain-snafu-1531240/), however, that issue most likely arose because a system designer decided to use an internal .xxx placeholder after the TLD was delegated and not before. No form of mitigation can prevent the collision of a name after the TLD has been delegated.
- New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis.
- Indeed, on the same day that the Interisle report was published, VeriSign published research that it described as “one of the largest investigations of DNS root zone traffic to date, with DNS queries from up to 11 of the 13 root instances, dating back to 2006.”
- Jeremy Rowley, DigiCert Inc, DigiCert’s Comments on new gTLD Collision Mitigation, August 27, 2013
- Supra, Note 7.
- A Word on Weighting. The model does not apply a qualitative weight to each of the risk factors. These weights can be adjusted based on qualitative assumptions (which would devalue the quantitative purpose of the analysis. By nature of the equation, two factors (Domain Name Queries and SSL Certificates) have the most impact on the outcome.