Latest news of the domain name industry

Recent Posts

A new way to game the new gTLD program

Kevin Murphy, May 13, 2024, Uncategorized

It may not help you win a gTLD, but a new method for screwing over your enemies in ICANN’s new gTLD program has emerged.

As I reported earlier today, it seems quite likely that ICANN is going to add a new step in the new gTLD evaluation process for the next round — testing each applied-for string in the live DNS to see if it causes significant name collision problems, breaking commonly deployed software or leading to data leaks.

The proposed new Technical Review Team would make this assessment based in part on how much query traffic non-existent TLDs receive at various places in the DNS, including the ICANN-managed root. A string with millions of daily queries would be flagged for further review and potentially banned.

The Name Collision Analysis Project Discussion Group, which came up with the new name collisions recommendations, reckons this fact could be used against new gTLD applicants as a form of sabotage, as it might be quite difficult for ICANN to figure out whether the traffic is organic or simulated.

The group wrote in its final report (pdf):

In the 2012 round, the issue of name collisions included an assumption that the existence of any name collision was accidental (e.g., individuals and organizations that made a mistake in configuration). In future rounds, there is a concern on the part of the NCAP DG that name collisions will become purposeful (e.g., individuals and organizations will simulate traffic with an intention to confuse or disrupt the delegation process)…

Determining whether a name collision is accidental or purposeful will be a best-effort determination given the limits of current technologies.

We’re basically talking about a form of denial of service attack, where the DNS is flooded with bogus traffic with the intention of breaking not a server or a router but a new gTLD application filed by a company you don’t like.

It probably wouldn’t even be that difficult or expensive to carry out. A string needs fewer than 10 million queries a day to make it into the top 25 non-existent TLDs to receive traffic.

It would make no sense if the attacker was also applying for the same gTLD — because it’s the string, not the applicant, that gets banned — but if you’re Pepsi and you want to scupper Coca-Cola’s chances of getting .coke, there’s arguably a rationale to launch such an attack.

The NCAP DG noted that such actions “may also impact the timing and quantity of legal objections issued against proposed allocations, how the coordination of the next gTLD round is designed, and contention sets and auctions.”

“Name collisions are now a well-defined and known area of concern for TLD applicants when compared to the 2012 round, which suggests that individuals and organizations looking to ‘game’ the system are potentially more prepared to do so,” the report states.

I’d argue that the potential downside of carrying out such an attack, and getting found out, would be huge. Even if it turns out not to be a criminal act, you’d probably find yourself in court, with all the associated financial and brand damage that would cause, regardless.

.home, .mail and .corp could get unbanned

Kevin Murphy, May 13, 2024, Domain Tech

The would-be new gTLDs .home, .mail and .corp — which were some of the most hotly contested strings in the 2012 application round before ICANN banned them — could get a new lease of life if ICANN adopts the recommendations of a panel of security experts.

More than 20 applications for the three strings were first put on hold, and then rejected outright in 2018, due to the risk of name collisions — where a TLD in the public DNS clashes with a domain used extensively on private networks.

The three non-existent TLDs receive more than 100 million queries per day at the DNS root due to queries leaking out from private networks, creating the risk of stuff breaking or sensitive data being stolen if they were to ever be delegated.

But now ICANN has been told that it “should not reject a TLD solely based on the volume of name collisions” and that it should submit .home, .mail and .corp to a new, more nuanced “Name Collision Risk Assessment Process”.

The recommendations comes in a newly published and rather extensive final report (pdf) from the Name Collision Analysis Project Discussion Group, which has been looking into the name collisions problem for the last four years.

While NCAP says ICANN should create a Collision String List of high-risk strings that new gTLD applicants could consult, it stopped short of recommending that the Org preemptively ban strings outright with a “do not apply” list, writing:

Regarding .CORP, .HOME, and .MAIL, high query volume is not a sufficient indicator of high-risk impact. The complexity and diversity of query sources further complicate the assessment of risk and impact. It is impractical to create a pre-emptive “do-not-apply” list for gTLD strings due to the dynamic nature of the DNS and the need for real-time, comprehensive analysis.

.corp might have a relatively easier time getting unblocked. NCAP figured out that most queries for that TLD are due to one “globally dominant software package” made by Microsoft that uses .corp as a default setting. This problem would be easier to fix than .home, which sees bogus traffic from a huge range of sources.

.mail also might be safe to delegate. NCAP noted that at least six gTLDs with more pre-delegation query traffic — .network, .ads, .prod, .dev, .office and .site — were subsequently delegated and received very low numbers of collision reports from live deployment.

Instead of banning any string, NCAP instead proposes a new Name Collision Risk Assessment Framework.

Under the framework, a new Technical Review Team would be in charge of testing every applied-for gTLD not already considered high risk for collision risks and placing the high-risk ones on a Collision String List of essentially banned strings.

To do so, the applied-for gTLD string would have to be actually delegated to the live DNS root zone, under the control of the TRT rather than a registry or applicant, while data is gathered using four different methods of responding to query traffic not unlike the “controlled interruption” method currently in use.

This would be a huge break from the current system, under which gTLDs only get delegated after ICANN has contracted with a registry operator, but it would mean that IANA would be able to quickly yank a gTLD from the DNS, if it started causing serious problems, without stepping on anyone’s commercial interests or inviting legal action.

There’s little doubt that the proposed framework would add friction to the new gTLD evaluation process in the next round, but the fact that NCAP has delivered its recommendations ahead of its original schedule is good news for those hoping for no more delays to the next round actually launching.

The NCAP study was considered on the critical path to the next round. It’s already been approved by the Security and Stability Advisory Committee and is expected to be considered by ICANN’s board of directors at an upcoming meeting. Implementing the recommendations would obviously take some time, but I doubt that would delay the expected Q2 2026 opening of the next application window.

The new recommendations on .corp, .home and .mail mean those gTLDs could well come back into play in the next round, which will come as cold comfort to the applicants who had their $185,000 application fees tied up for years before ICANN finally decided to ban them in 2018, offering a full refund.

There were seven applicants for .mail, six for .corp, and a whopping 11 for .home. Applicants included GoDaddy, Google, Amazon, and Identity Digital.

According to ICANN’s web site, Google never actually withdrew its applications for .home, .corp and .mail, and Amazon never withdrew its application for .mail. If that’s accurate, it could lead to some interesting disputes ahead of the 2026 application round.