POSTS TAGGED: icann
Burt Kaliski | Nov 20, 2013
ICANN’s second level domain (SLD) blocking proposal includes a provision that a party may demonstrate that an SLD not in the initial sample set could cause “severe harm,” and that SLD can potentially be blocked for a certain period of time. The extent to which that provision would need to be exercised remains to be determined. However, given the concerns outlined in Part 2 and Part 3 of this series, it seems likely that there could be many additions (and deletions!) from the blocked list given the lack of correlation between the DITL data and actual at-risk queries.
If the accumulated risk from non-blocked SLDs were to become too large, it could become necessary for ICANN to withdraw the entire gTLD from the global DNS root. Changes to the DNS root, once properly approved and authorized, can be implemented rapidly by updating the root zone file and notifying root server operators that a new zone file is available. This part of the process is as straightforward for deletions as for additions. The approval and authorization process, however, would need to be much faster for a deletion than it currently is for an addition because of the urgency of making the change or “rollback” after a determination was reached that a gTLD’s delegation needed to be revoked. The importance of rapid delegation is affirmed in Recommendation 3 of SAC062: Advisory Concerning the Mitigation of Name Collision Risk, published Nov. 7 by ICANN’s Security and Stability Advisory Committee (SSAC):
Burt Kaliski | Nov 13, 2013
As discussed in the several studies on name collisions published to date, determining which queries are at risk, and thus how to mitigate the risk, requires qualitative analysis (New gTLD Security and Stability Considerations; New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis; Name Collisions in the DNS). Blocking a second level domain (SLD) simply on the basis that it was queried for in a past sample set runs a significant risk of false positives. SLDs that could have been delegated safely may be excluded on quantitative evidence alone, limiting the value of the new gTLD until the status of the SLD can be proven otherwise.
Similarly, not blocking an SLD on the basis that it was not queried for in a past sample set runs a comparable risk of false negatives.
A better way to deal with the risk is to treat not the symptoms but the underlying problem: that queries are being made by installed systems (or internal certificates are being employed by them) under the assumption that certain gTLDs won’t be delegated.
Burt Kaliski | Nov 08, 2013
For several years, DNS-OARC has been collecting DNS query data “from busy and interesting DNS name servers” as part of an annual “Day-in-the-Life” (DITL) effort (an effort originated by CAIDA in 2002) that I discussed in the first blog post in this series. DNS-OARC currently offers eight such data sets, covering the queries to many but not all of the 13 DNS root servers (and some non-root data) over a two-day period or longer each year from 2006 to present. With tens of billions of queries, the data sets provide researchers with a broad base of information about how the world is interacting with the global DNS as seen from the perspective of root and other name server operators.
In order for second level domain (SLD) blocking to mitigate the risk of name collisions for a given gTLD, it must be the case that the SLDs associated with at-risk queries occur with sufficient frequency and geographical distribution to be captured in the DITL data sets with high probability. Because it is a purely quantitative countermeasure, based only on the occurrence of a query, not the context around it, SLD blocking does not offer a model for distinguishing at-risk queries from queries that are not at risk. Consequently, SLD blocking must make a stronger assumption to be effective: that any queries involving a given SLD occur with sufficient frequency and geographical distribution to be captured with high probability.
Put another way, the DITL data set – limited in time to an annual two-day period and in space to the name servers that participate in the DITL study – offers only a sample of the queries from installed systems, not statistically significant evidence of their behavior and of which at-risk queries are actually occurring.
Burt Kaliski | Nov 06, 2013
As widely discussed recently, observed within the ICANN community several years ago, and anticipated in the broader technical community even earlier, the introduction of a new generic top-level domain (gTLD) at the global DNS root could result in name collisions with previously installed systems. Such systems sometimes send queries to the global DNS with domain name suffixes that, under reasonable assumptions at the time the systems were designed, may not have been expected to be delegated as gTLDs. The introduction of a new gTLD may conflict with those assumptions, such that the newly delegated gTLD collides with a domain name suffix in use within an internal name space, or one that is appended to a domain name as a result of search-list processing.
Verisign Labs conducted two research studies earlier this year on the evidence for and risks of potential name collisions between installed systems and applied-for gTLDs. The studies confirmed that a large number of queries currently processed by the DNS root servers do indeed include domain name suffixes that match applied-for gTLDs and therefore could be at risk if the behavior of the global DNS were to change.
Pat Kane | Oct 23, 2013
On Oct. 23, 2013, at approximately 11:00 a.m. EDT, Verisign received authorization instructions from the U.S. Department of Commerce National Telecommunications and Information Administration (NTIA) to delegate four new gTLDs into the root zone, which we are responsible for maintaining per the Cooperative Agreement between Verisign and NTIA. Verisign acted in accordance with our contractual obligation and delegated these TLDs into the root zone at 2:33 p.m. EDT the same day.
Verisign has entered the ASCII versions of the strings listed below into the DNS root, now making these gTLDs live.
- .сайт (XN--80ASWG): Russian word for “Web site”
- .онлайн (XN--80ASEHDB) Russian word for “.online”
- شبكة. (XN--NGBC5AZD) Arabic word for “Web” or “Network,” and;
- .游戏 (XN--UNUP4Y) Chinese word for “Game”