A name collision occurs when a user attempts to resolve a domain in one namespace, but it unexpectedly resolves in a different namespace. Name collision issues in the public global Domain Name System (DNS) cause billions of unnecessary and potentially unsafe DNS queries every day. A targeted outreach program that Verisign started in March 2020 has remediated one billion queries per day to the A and J root name servers, via 46 collision strings. After contacting several national internet service providers (ISPs), the outreach effort grew to include large search engines, social media companies, networking equipment manufacturers, national CERTs, security trust groups, commercial DNS providers, and financial institutions.(more…)
Recent comments on the name collisions issue in the new gTLD program raise a question about the differences between established and new gTLDs with respect to name collisions, and whether they’re on an even playing field with one another.
Verisign’s latest public comments on ICANN’s “Mitigating the Risk of DNS Namespace Collisions” Phase One Report, in answering the question, suggest that the playing field the industry should be concerned about is actually in a different place. The following points are excerpted from the comments submitted April 21.
Verisign posted preliminary public comments on the “Mitigating the Risk of DNS Namespace Collisions” Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done.
Presentations, papers and video recordings from the name collisions workshop held earlier this month in London are now available at the workshop web site, namecollisions.net.
The goal for the workshop, described in my “colloquium on collisions” post, was that researchers and practitioners would “speak together” to keep name spaces from “striking together.” The program committee put together an excellent set of talks toward this purpose, providing a strong, objective technical foundation for dialogue. I’m grateful to the committee, speakers, attendees and organizers for their contributions to a successful two-day event, which I am hopeful will have benefit toward the security and stability of internet naming for many days to come.
I’m delighted to announce that the name collisions workshop this weekend will include Jeff Schmidt, CEO of JAS Global Advisors, presenting the Name Collision Occurrence Management Framework that his firm just released for public review.
Jeff’s presentation is one of several on the program announced by the program committee for the Workshop and Prize on Root Causes and Mitigations of Name Collisions (WPNC).
The Mitigating the Risk of DNS Namespace Collisions report, just published by JAS Global Advisors, under contract to ICANN, centers on the technique of “controlled interruption,” initially described in a public preview shared by Jeff Schmidt last month.
With that technique, domain names that are currently on one of ICANN’s second-level domain (SLD) block lists can be registered and delegated for regular use, provided that they first go through a trial period where they’re mapped to a designated “test” address. The staged introduction of new SLDs is intended to provide operators of installed systems the opportunity to assess the potential impact of an impending name collision on their own, before any external operators have an opportunity to exploit it.
There may still be a few security practitioners working in the field who didn’t have a copy of Bruce Schneier’s Applied Cryptography on their bookshelf the day they started their careers. Bruce’s practical guide to cryptographic algorithms, key management techniques and security protocols, first published in 1993, was a landmark volume for the newly emerging field, and has been a reference to developers ever since.
Beyond just the popularity of the book, Bruce has also been widely recognized over the past two decades for his insightful commentary on the security issues of the day, featured on his monthly Crypto-Gram newsletter, his blog, “Schneier on Security,” 11 more books including the newly published Carry On, as well as numerous essays, op-eds and interviews.
It’s a genuine privilege therefore that Bruce will be keynoting the upcoming Name Collisions Workshop, to be held on March 8-10, in London.
According to the Online Etymology Dictionary, the verb collide is derived from the Latin verb collidere, which means, literally, “to strike together”: com- “together” + lædere “to strike, injure by striking.”
Combined instead with loquium, or “speaking,” the com- prefix produces the Latin-derived noun colloquy: “a speaking together.”
Researchers and practitioners know well the benefits of the colloquium, the technical conference, a gathering of those speaking together on a topic.
So consider WPNC 14 – the upcoming namecollisions.net workshop – a colloquium on collisions: speaking together to keep name spaces from striking together.
Many years ago on my first trip to London, I encountered for the first time signs that warned pedestrians that vehicles might be approaching in a different direction than they were accustomed to in their home countries, given the left-versus-right-side driving patterns around the world. (I wrote a while back about one notable change from left-to-right, the Swedish “H Day,” as a comment on the IPv6 transition.)
If you’re not sure on which side to expect the vehicles, it’s better to look both ways — and look again — if you want to reduce the risk of a collision.
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.