NordVPN Promotion

Home / Blogs

Whatever Happened with Namespace Collision Issues and the gTLD Round of 2012

Protect your privacy:  Get NordVPN  [73% off 2-year plans, 3 extra months]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

The new gTLD program of 2012, based on the Generic Names Supporting Organization (GNSO) policy recommendations of 2007, has been both a success and mess. In terms of its success, many new and innovative names are being introduced on the Internet, more most every day. The mess has involved ad-hoc, independent decisions by the Board and implementation decisions by ICANN staff that have resulted in variety of problems including a broken community evaluation process, invention of new Rights Protection Mechanisms (RPMs which deal only with one type of rights, Intellectual Property rights), the absence of reasonable appeals mechanisms, inconsistent results on confusingly similar names, and unilateral changes to the pre-defined registry contract; just to mention a few. While it has been said before, it bears repeating: the program failed to live up to the first principle of the GNSO new gTLD policy recommendations of 2007:

New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way.

Although not firmly based on the approved GNSO policy recommendations of 2007, ICANN staff created an Application Guide Book (AGB) meant to represent the commitment of ICANN to the “orderly, timely and predictable process.” People signed contracts and paid their money for a process that had been defined in gory detail. Yet time and time again, this AGB has been supplemented and altered after the beginning of the application process. This post-contract change of material conditions has often been done without any policy involvement from the GNSO. Unfortunately, the process of ad hoc policy making by the Board continues to this day, years later.

One of the areas in which ICANN continues to act without community policy guidance has been the area of namespace collisions in which delegation of new gTLDs might conflict with names that are currently being used in an unsanctioned manner by the general public. For years, undelegated gTLDs have been used by local networks and intranets to serve a variety of purposes. In October of 2015, a final report on Mitigating the Risk OF DNS Namespace Collisions was released by JAS Global Advisors and is commonly referred to as the JAS report*. The first draft of this report was released in 2014 and while it received a certain amount of comment, it did not lead to a policy process in the GNSO. As it currently stands, the report is just a set of recommendations, but there was a plan to provide “the ICANN Board New gTLD Program Committee with a proposal to address name collisions for new gTLDs as part of the New gTLD Collision Occurrence Management Plan.” This plan is based on a Board decision in 2013 that directed “the implementation of the New gTLD Collision Occurrence Management Plan, and provides recommendations to the Board regarding follow-up items to manage name collision.” All of this without any GNSO Policy Development Process (PDP) or even consultation with the GNSO. As the Board stated, this was intended “to exercise the ICANN Board’s authority for any and all issues that may arise relating to the New gTLD Program.” The final JAS report has not been subject to community review and comment. Whatever may be in store for the future is a mystery. Determining the current state of the New gTLD Collision Occurrence Management Plan is challenging. And yet, there have been applications for names, such as .corp, .home and .mail (CHM), that remain in limbo awaiting disposition by the Board—so much for predictability.

The JAS report makes for interesting reading and provides good background on namespace collision issues, such as misdirection of web requests and misdirection of email. The report also includes 14 recommendations for how to handle a variety of name collisions. Recommendation 3 states:

Emergency response options are limited to situations where there is a reasonable belief that the DNS namespace collision presents a clear and present danger to human life.

This seems to be a very wise recommendation that provides a sufficiently high barrier. In most cases, the report recommends controlled delegation and the introduction of mitigation techniques to handle the possibility of collisions. The report gives a good description of many possible mitigation techniques that can be used to allow gTLDs considered collision risks to be delegated.

But not .corp, .home and .mail; these have been singled out for special status by this report. Though there is no indication that delegation of these names would cause any risk to human or other life, Recommendation 1 states that:

“The TLDs .corp, .home, and .mail be referred to the Internet Engineering Task Force (IETF) for potential RFC 1918-like protection/treatment.”

That is, these names would be added to a reserved names list, making them ineligible for delegation after having already accepted applications for them and having the applications pass security, stability and technical standards. Leaving aside the question of whether the IETF is ready to take this issue on (to date, the IETF has declined to proceed), the idea that after allowing applicants to apply for these names, they would just be added to the reserve list is difficult to understand. Why wouldn’t those who applied for these names be given a chance to develop appropriate mitigation techniques? While studies indicate that these names are more likely to result in collisions than many of the other names, there is no credible evidence that developing mitigation techniques for these names would be impossible. Though perhaps challenging, it has not been tried and possible solutions have not been tested.

It is also difficult, from a policy development perspective, to understand how ICANN could decide to make a policy decision requesting that names be added to the reserved names list without consulting those responsible for gTLD policy, i.e. the GNSO. The gTLD policy recommendations of 2007 included a discussion on reserved names based on subcommittee work done during the PDP and a recommendation that ‘names thought likely to cause name collisions be reserved’ was not included. The first Security and Stability Advisory Committee advisory on namespace collisions was not released until 2013, in SSAC062 Advisory Concerning the Mitigation of Name Collision Risk. The fact that the issue was not discussed by the GNSO because the problem had not yet been brought forward is not a justification for the Board to make a policy decision without a proper policy development process. Making such decisions without proper bottom-up processes seems to go beyond the Board’s remit. A request to the IETF for action related to gTLDs should require a recommendation from the GNSO and community comment, before such a request is made.

Another question that comes up is: what happens to those who have applied for these names in good faith? Is “money down the drain” something to be expected when an applicant follows all of ICANN’s rules for an application? Is that what ICANN means by orderly, timely and predictable? Will the applicants be offered their money back if such a decision is made?

I have barely scratched the surface of some of the questions that remain dangling in this chapter of the gTLD program of 2012. It seems to me that there should be an organized community process to deal with the issues that have been described in the JAS Report. The recommendations made in this report, as well as the relevant SSAC advisories should be reviewed by the GNSO and there should be a determination of what should be adopted by the Board and what should not. There should also be an opportunity for those who have applied for these domain names to develop possible mitigation strategies, either individually or as a collaborative group, that would satisfy DNS stability concerns.

There needs to be an open and transparent airing of all issues related to the subject of namespace collisions. As the ICANN community embarks on a multitude of reviews of the last round and starts to prepare for a possible subsequent round, we must, as a community, determine the right course to take on the issues of namespace collisions, including the disposition of .corp, home and .mail.

* JAS Report: Not to be confused with the JAS (Joint Working Group on Applicant Support) report that was issued on methods of assisting applicants from developing economies in the gTLD round of 2012.

By Avri Doria, Researcher

Filed Under

Comments

Interesting Jean Guillon  –  Mar 3, 2016 3:42 PM

Nothing said about the “.SUCKS” new gTLD?

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Cybersecurity

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

DNS

Sponsored byDNIB.com

NordVPN Promotion