Tag: new_gtlds

Nov262013 by editorNo Comments

Verisign Part 4 of 4: SLD Blocking Is Too Risky without TLD Rollback

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 prop

Nov142013 by editorNo Comments

Verisign Part 3 of 4: Name Collision Mitigation Requires Qualitative Analysis

Domains

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 co

Nov112013 by editorNo Comments

Verisign Part 2 of 4:New gTLD’s Domain blocking not sufficient

Cyber Security, Domains

Part 2 of 4 – DITL Data Isn’t Statistically Valid for This Purpose 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 sec

Nov72013 by editorNo Comments

Verisign: ICANN’s Alternative Path to Delegation

Domains

Part 1 of 4 – Introduction: ICANN’s Alternative Path to Delegation 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 appen