Wanted: a gTLD to ban

ICANN may have failed so far to deliver a way for the world to create any more gTLDs, but it’s about to pick a string that it will resolve to never, ever delegate.

It’s going to designate an official “private use” string, designed for organizations to use behind their own firewalls, and promise that the chosen string will never make it to the DNS root.

IP lawyers and new gTLD consultants might want to keep an eye on this one.

The move comes at the prompting of the Security and Stability Advisory Committee, which called for ICANN to pick a private-use TLD in a September 2020 document (pdf).

ICANN hasn’t picked a string yet, but it has published its criteria for public comment:

1. It is a valid DNS label.
2. It is not already delegated in the root zone.
3. It is not confusingly similar to another TLD in existence.
4. It is relatively short, memorable, and meaningful.

The obvious thing to do would be to pick one of the 42 strings ICANN banned in the 2012 new gTLD round, which includes .example, .test and .invalid, or one of the three strings it subsequently decided were too risky to go in the root due to their extensive use on private networks — .corp, .mail and .home.

The SSAC notes in its document that ICANN’s two root server constellations receive about 854 million requests a day for .home — the most-used invalid TLD — presumably due to leaks from corporate networks and home routers.

But .homes (plural) is currently in use — XYZ.com manages the registry — so would .home fail the “confusingly similar” test? Given that it’s already established ICANN policy that plurals should be banned in the next round, .home could be ruled out.

ICANN’s consultation doesn’t make mention of whether gTLDs applied for in subsequent rounds would be tested for confusing similarity against this currently theoretical private-use string, but it seems likely.

Anyone considering applying for a gTLD in future will want to make sure the string ICANN picks isn’t too close to their brands or gTLD string ideas. Its eventual choice of string will also be open for public comment.

There don’t seem to be a massive amount of real-world benefits to designating a single private-use TLD string.

Nobody would be obliged to use it in their kit or on their networks, even if they know it exists, and ICANN’s track record of reaching out to the broader tech sector isn’t exactly stellar (see: universal acceptance). And even if everyone currently using a different TLD in their products were to switch to ICANN’s choice, it would presumably take many years for currently deployed gear to cycle out of usage.

It’s ICANN versus the blockchain in Kuala Lumpur

Internet fragmentation and the rise of blockchain-based naming systems were firmly on the agenda at ICANN 75 in Kuala Lumpur today, with two sessions exploring the topic and ICANN’s CTO at one point delivering a brutal gotcha to a lead blockchain developer.

Luc van Kampen, head of developer relations at Ethereum Name Service, joined a panel entitled Emerging Identifier Technologies, to talk up the benefits of ENS.

He did a pretty good job, I thought, delivering one of the clearest and most concise explanations of ENS I’ve heard to date.

He used as an example ICANN’s various handles across various social media platforms — which are generally different depending on the platform, because ICANN was late to the party registering its name — to demonstrate the value of having a single ENS name, associated with a cryptographic key, that can be used to securely identify a user across the internet.

Passive aggressive? Maybe. But it got his point across.

“We at ENS envisage a world where everyone can use their domain as a universal identifier,” he said. Currently, 600,000 users have registered 2.4 million .eth domains, and over 1,000 web sites support it, he said.

He described how ENS allows decentralized web sites, is managed by a decentralized autonomous organization (DAO) and funded by the $5 annual fee for each .eth name that is sold.

Van Kampen had ready responses to questions about how it would be feasible for ENS to apply to ICANN to run .eth in the consensus root in the next new gTLD application round, suggesting that it’s something ENS is thinking about in detail.

While not confirming that ENS will apply, he described how a gateway or bridge between the Ethereum blockchain and the ICANN root would be required to allow ENS to meet contractual requirements such as zone file escrow.

What did not come up is the fact the the string “eth” is likely to be reserved as the three-character code for Ethiopia. If the next round has the same terms as the 2012 round, .eth will not even enter full evaluation.

But the real gotcha came when ICANN CTO John Crain, after acknowledging the technology is “really cool”, came to ask a question.

“What kind of safeguards and norms are you putting in place regarding misbehavior and harm with these names?” Crain asked.

Van Kampen replied: “Under the current implementation of the Ethereum Name Service and the extensions that implement us and the integrations we have, domains are unable to be revoked under any circumstances.”

“So if I understand correctly, under the current solution, if I’m a criminal and I register a name in your space, I’m pretty secure today,” Crain asked. “I’m not going to lose my name?”

Van Kampen replied: “Under the current system, everything under the Ethereum Name Service and everything registered via us with the .eth TLD are completely censorship resistant.”

Herein lies one of the biggest barriers to mainstream adoption of blockchain-based alt-roots. Who’s going to want to be associated with a system that permits malware, phishing, dangerous fake pharma and child sexual abuse material? Who wants to be known as the maker of the “kiddy porn browser”?

If I were Crain I’d be feeling pretty smug after that exchange.

That’s not to say that ICANN put in a wholly reassuring performance today.

Technologist Alain Durand preceded van Kampen with a presentation pointing out the substantial problems with name collisions that could be caused by blockchain-based alt-roots, not only between the alt-root and the ICANN root, but also between different alt-roots.

It’s a position he outlined in a paper earlier this year, but this time it was supplemented with slides outlining a hypothetical conversation between two internet users slowly coming to the realization that different namespaces are not compatible, and that the ex-boyfriend of “Sally” has registered a name that collides with current boyfriend “John”.

It’s meant to be cute, but some of the terminology used made me cringe, particularly when one of the slides was tweeted out of context by ICANN’s official Twitter account.

To learn more about alternative naming systems, read #ICANN's OCTO publication >> https://t.co/LFYjy1KX3w | Emerging Identifier Technologies #ICANN75 pic.twitter.com/mWN7fCc7eR

— ICANN (@ICANN) September 21, 2022

Maybe I’m reading too much into this, but it strikes me as poor optics for ICANN, an organization lest we forget specifically created to introduce competition to the domain name market, to say stuff like “Market, you are a monster!”.

I’m also wondering whether “icannTLD” is terminology that plays into the alt-root narrative that ICANN is the Evil Overlord of internet naming. It does not, after all, actually run any TLDs (except .int).

The language used to discuss alt-roots came under focus earlier in the day in a session titled Internet Fragmentation, the DNS, and ICANN, which touched on blockchain alt-roots while not being wholly focused on it.

Ram Mohan, chief strategy officer of Identity Digital and member of ICANN’s Security and Stability Advisory Committee, while warning against ICANN taking a reflexively us-versus-them stance on new naming systems, wondered whether phrases such as “domain name” and “TLD” are “terms of art” that should be only used to refer to names that use the consensus ICANN-overseen DNS.

We ought to have a conversation about “What is a TLD”? Is a TLD something that is in the IANA root? Is a domain name an identifier that is a part of that root system? i think we ought to have that conversation because the place where I worry about is you have other technologies in other areas that come and appropriate the syntax, the nomenclature, the context that all of us have worked very hard to build credibility in… What happens if that terminology gets taken over, diluted, and there are failures in that system? … The end user doesn’t really care whether [a domain] is part of the DNS or not part of the DNS, they just say “My domain name stopped working”, when it may not actually be a quote-unquote “domain name”.

Food for thought.

Uniregistry to release 10 million domains on October 4

Uniregistry plans to release millions of registry-reserved domain names, many at standard registration fee, two weeks from now.
The company, which has about 25 new gTLDs in its stable, will release 10 million currently reserved names on October 4, CEO Frank Schilling told DI.
The revelation follows news that the company has started allowing thousands of registry-owned domains to expire and return to the available pool.
About 200,000 domains originally registered to North Sound Names, a separate Schilling-controlled company, are being made available via regular channels.
Those domains were registered (rather than reserved) so that Uniregistry could throw up landing pages inviting potential buyers to make offers. After they drop, they will no longer resolve.
But Schilling said a further 9.8 million names will also hit the market next month.
“It’s just a much better time because we have greater distribution and we are less likely to see all our names taken at land rush by one or two commercial registrants,” he said.
“We are unblocking and deleting 10 million domain names and making them available for registration through more than 200 registrars,” he said.
“Almost all will be standard reg [fee],” he said, when asked about pricing. Others will carry premium fees.
A web site publishing lists of newly released names will go live in about a week, he said.
DNW has previously reported that Uniregistry plans to release names that were initially blocked due to ICANN’s name collisions mitigation plan.
Those lists (which are usually mostly junk) are already published by ICANN and can be found accompanying the Registry Agreement for the relevant TLD linked from this page. Here’s the 35,000-name .link collisions list (.csv) for example.

Are .mail, .home and .corp safe to launch? Applicants think so

ICANN should lift the freeze on new gTLDs .mail, .home and .corp, despite fears they could cause widespread disruption, according to applicants.
Fifteen applicants for the strings wrote to ICANN last week to ask for a risk mitigation plan that would allow them to be delegated.
The three would-be gTLDs were put on hold indefinitely almost three years ago, after studies determined that they were at risk of causing far more “name collision” problems than other strings.
If they were to start resolving on the internet, the fear is they would lead to problems ranging from data leakage to systems simply stopping working properly.
Name collisions are something all new TLDs run the risk of creating, but .home, .corp and .mail are believed to be particularly risky due to the sheer number of private networks that use them as internal namespaces.
My own ISP, which has millions of subscribers, uses .home on its home hub devices, for example. Many companies use .corp and .mail on their LANs, due to longstanding advice from Microsoft and the IETF that it was safe to do so.
A 2013 study (pdf) showed that .home received almost 880 million DNS queries over a 48-hour period, while .corp received over 110 million.
That was vastly more than other non-existent TLDs.
For example, .prod (which some organizations use to mean “production”) got just 5.3 million queries over the same period, and when Google got .prod delegated two years it prompted an angry backlash from inconvenienced admins.
While .mail wasn’t quite on the same scale as the other two, third-party studies determined that it posed similar risks to .home and .corp.
All three were put on hold indefinitely. ICANN said it would ask the IETF to consider making them officially reserved strings.
Now the applicants, noting the lack of IETF movement to formally freeze the strings, want ICANN to work on a thawing plan.
“Rather than continued inaction, ICANN owes applicants for .HOME, .CORP, and .MAIL and the public a plan to mitigate any risks and a proper pathway forward for these TLDs,” the applicants told ICANN (pdf) last Wednesday.
A December 2015 study found that name collisions have occurred in new gTLDs, but that no truly serious problems have been caused.
That does not mean .home, .corp and .mail would be safe to delegate, however.

New ccTLDs may have to block name collisions

ICANN is thinking about expanding its controversial policy on name collisions from new gTLDs to new ccTLDs.
The country code Names Supporting Organization has been put on notice (pdf) that ICANN’s board of directors plans to pass a resolution on the matter shortly.
The resolution would call on the ccNSO to “undertake a study to understand the implications of name collisions associated with the launch of new ccTLDs” including internationalized domain name ccTLDs, and would “recommend” that ccTLD managers implement the same risk mitigation plan as new gTLDs.
Because ICANN does not contract with ccTLDs, a recommendation and polite pressure is about as far as it can go.
Name collisions are domains in currently undelegated TLDs that nevertheless receive DNS root traffic. In some cases, that may be because the TLDs are in use on internal networks, raising the potential of data leakage or breakages if the TLDs are then delegated.
ICANN contracts require new gTLDs to block such names or wildcard their zones for 90 days after launch.
Some new gTLD registry executives have mockingly pointed to the name collisions issue whenever a new ccTLD has been delegated over the last year or so, asking why, if collisions are so important, the mitigation plan does not apply to ccTLDs.
If the intent was to persuade ICANN that the collisions management framework was unnecessary, the opposite result has been achieved.

.top says Facebook shakedown was just a typo

Jiangsu Bangning Science & Technology, the .top registry, is blaming a typo for a Facebook executive’s claim that it wanted $30,000 or more for facebook.top.
Information provided to the ICANN GNSO Council by Facebook domain manager Susan Kawaguchi yesterday showed that .top wanted RMB 180,000 (currently $29,000) for a trademarked name that previously had been blocked due to ICANN’s name collisions policy.
But Mason Zhang, manager of the registry’s overseas channel division, told DI today that the price is actually RMB 18,000 ($2,900):

We were shocked when seeing that our register price for TMCH protected names like Facebook during Exclusive Registration Period is changed from “eighteen thousand” into what is written, the “one hundred and eighty thousand”.
I think that might be a type mistake from our side, and we checked and we are certain that the price is CNY EIGHTEEN THOUSAND.

The 18,000-yuan sunrise fee is published on the registry’s official web site, as I noted yesterday.
The registry email sent to Facebook is reproduced in this PDF.
I wondered yesterday whether a breakdown in communication may to be blame. Perhaps I was correct.
While $3,000 is still rather high for a defensive registration, it doesn’t stink of extortion quite as badly as $30,000.
Still, it’s moderately good news for Facebook and any other company worried they were going to have to shell out record-breaking prices to defensively register their brands.

Millions of new gTLD domains to be released as collision blocks end

Millions of new gTLD domain names are set to start being released, as ICANN-mandated name collision blocks start getting lifted.
Starting yesterday, domains that have been blocked from registration due to name collisions can now be released by the registries.
About 95,000 names in gTLDs such as .nyc, .tattoo, .webcam and .wang have already ended their mandatory “controlled interruption” period and hundreds of thousands more are expected to be unblocked on a weekly basis over the coming months (and years).
Want to register sex.nyc, poker.bid or garage.capetown? That may soon be possible. Those names, along with hundreds of other non-gibberish domains, are no longer subject to mandatory blocks.
Roughly 45 new gTLDs have ended their CI periods over the last two days. Here are the Latin-script ones:

.bid, .buzz, .cancerresearch, .capetown, .caravan, .cologne, .cymru, .durban, .gent, .jetzt, .joburg, .koeln, .krd, .kred, .lacaixa, .nrw, .nyc, .praxi, .qpon, .quebec, .ren, .ruhr, .saarland, .wang, .webcam, .whoswho, .wtc, .citic, .juegos, .luxury, .menu, .monash, .physio, .reise, .tattoo, .tirol, .versicherung, .vlaanderen and .voting

Another half dozen or so non-Latin script gTLDs have also finished with CI.
There are over 17,500 newly unblocked names in .nyc alone. Over the whole new gTLD program, over 9.8 million name collisions are to be temporarily blocked.
Name collisions are domains in new gTLDs that were already receiving DNS root traffic well before the gTLD was delegated, suggesting that they may be in use on internal networks.
To avoid possible harm from collisions, ICANN forced registries to make these names unavailable for registration and to resolve to the deliberately non-functional and odd-looking IP address 127.0.53.53.
Each affected name had to be treated in this way for 90 days. The first TLDs started implementing CI on August 18, so the first batch of registries ended their programs yesterday.
So, will every domain that was on a registry’s collision list be available to buy right away?
No.
ICANN hasn’t told registries that they must release names as soon as their CI period is over, so it appears to be at the registries’ discretion when the names are released. I gather some intend to do so as soon as today.
Also, any name that was blocked due to a collision and also appears in the Trademark Clearinghouse will have to remain blocked until it has been subject to a Sunrise period.
Some registries, such as Donuts, have already made their collision names available (but not activated in the DNS) under their original Sunrise periods so will be able to release unclaimed names at the same time as all the rest.
Other registries will have to talk to ICANN about a secondary sunrise period, to give trademark holders their first chance to grab the previously blocked names.
Furthermore, domains that the registry planned to reserved as “premiums” will continue to be reserved as premiums.

Comcast users report name collision bugs

US cable ISP Comcast has become the latest company to experience problems caused by name collisions with new gTLDs.
In this case the gTLD in question is .network, which Donuts had delegated at the end of August.
Users of Comcast’s Xfinity service have been complaining about various issues linked to collisions ever since.
It turns out some Xfinity hubs use the domain home.network on residential networks and that this default configuration choice was not corrected by Comcast before .network went live.
The collision doesn’t appear to be causing widespread internet access issues — Xfinity has close to 20 million users so we’d have heard about it if the problems were ubiquitous — some things appear to be failing.
I’ve seen multiple reports of users unable to access storage devices on their local networks, of being unable to run the popular TeamSpeak conferencing software used by gamers, problems with installing RubyGems, and errors when attempting to use remote desktop tools.
Judging by logs published by affected users, Donuts has been returning the domain “your-dns-needs-immediate-attention.network” and the IP address 127.0.53.53.
Anyone Googling for 127.0.53.53 — the IP address selected to ICANN’s “controlled interruption” name collision management plan — will currently find this ad:

Cyrus Namazi, vice president of DNS industry engagement at ICANN, confirmed to DI that ICANN has received multiple reports of issues on Comcast residential networks and that ICANN has been in touch with the ISP.
Comcast is working on a permanent fix, he said.
Namazi said that ICANN has not received any complaints from users of other ISPs. Most collision-related complaints have been filed by residential users rather than companies, he said.

Victims of first confirmed new gTLD collision respond: “Fuck Google”

A number of companies have experienced errors on their networks due to collisions with a newly introduced gTLD.
The initial outcry from victims can be characterized as a storm of profanity, which it could be argued is a good thing for security but not great for ICANN’s reputation.
The collisions, which I believe are the first to be publicly and widely reported, are due to Google’s new gTLD .prod, which was delegated September 1.
Google intends to use the TLD as a shorthand for “product”, but it seems some companies use it internally to mean “production”, meaning production servers rather than testing or development servers.
Issues started being reported on online fora on September 3, with Google unfairly bearing the brunt of the initial blame. Here are a few of the earliest examples from Twitter:

Hey Google, fuck you for making .prod a valid TLD, what the fuck is wrong with you

— eesperan (@eesperan) September 3, 2014

anyone else having fun name resolution issues because of the new .prod tld google just put online? http://t.co/jq104uAym0

— Chris Johnson (@point9repeating) September 3, 2014

.prod is now a TLD & basically broke the internet. (http://t.co/kB5JIZl1HE). This is why I didn't use prod as subdomain, @Drew_Stokes

— Allan Parsons (@allanparsons) September 3, 2014

Well .prod is now a TLD. Found out the fun way. #google #icann http://t.co/rbt4JIASgn

— jeremy avnet (@brainsik) September 3, 2014

A day later, Reddit user “cunttard”, under a post entitled “Fuck Google”, wrote:

Google recently activated prod. TLD.
They also decided to wildcard DNS all entries to 127.0.53.53 to resolve name collisions for internal organisations. All because they wanted .prod for product? Why not fucking request .product?
The implications have been fucking horrendous. I am in the process of helping a mate unfuck his organisations DNS, which heavily relied on resolver search $FQDN to map xyz.prod to xyz.prod.$FQDN. Note this wasn’t even used as an internal TLD. Now they’re all resolving short names to 127.0.53.53. Lesson learnt; always use FQDN everywhere.
I’m just fucking sick of ICANN / Google continuing to fuck DNS.

LinuxQuestions user “fantasygoat” started a thread entitled “New tLD .prod is messing with my configs”, in which he wrote:

I used to be able to refer to just the subdomain in a DNS lookup, like “www1.prod” and it would know I meant “www1.prod.example.com”, my local domain. I’ve been using prod.example.com for decades as the production subdomain for various things.
Now it resolves to 127.0.53.53, which I believe is ICANN’s hack DNS answer for tLDs.
So, I have a bunch of config files without the domain name and it’s messing stuff up. Does anyone have a workaround so I can have my DNS respond to .prod requests as a subdomain of my domain?

I’ve found a couple of other examples on various mailing lists and web forums with systems administrators experiencing similar issues over the last week.
This, it seems to me, shows that ICANN’s hack for mitigating the risks of name collisions, developed by JAS Advisors, is working as expected.
In each reported case of a .prod collision I’ve been able to find, the admin either had already worked out that he needed to use a fully-qualified domain name (eg www.prod.example.com instead of www.prod) or was swiftly advised to do so by those responding to his post.
Most seem to have spotted that instead of returning NXDOMAIN errors, Google is returning the IP address 127.0.53.53, which was chosen because it’s an internal IP and because 53 is the TCP/IP port number for DNS.
Diverting to 127.0.53.53 is designed to catch the eye, alerting admins to the need to correctly configure their networks.
It certainly seems to be doing that, but it’s not winning ICANN or new gTLD registries any new friends.
Nobody has yet reported death or injury due to a collision.
Update: There has been one previously reported collision, concerning .guru.

Blocked trademarks still eligible for Donuts sunrises

Donuts has confirmed that it is to allow trademark owners to participate in its new gTLD Sunrise periods even if their marks appear on name collisions block-lists.
The decision means that companies will be able to choose whether to grab names matching their marks during Sunrise, or take the risk that they will be released at a later date.
Donuts, like all gTLD registries, has been given block-lists for each of its TLDs. The idea is to avoid collisions with names already in use on private name-spaces behind corporate firewalls.
Lots of these blocked names match or contain well-known trademarks.
(Trademark owners can use the DI PRO collisions search engine to figure out which gTLDs have been asked to block their marks.)
While this appears at first glance to be good news for mark owners that just want their marks blocked in as many TLDs as possible, it also poses potential risks.
Blocked names are not likely to be blocked until after the first wave of Sunrise periods are over, and ICANN’s unblocking process has not yet been written.
For a company that wants to register its brand in a new gTLD, but is on a block-list, that could cause problems.
By allowing companies to participate in Sunrise regardless, Donuts is giving them a way to mitigate the risk of somebody else grabbing their brands in future.
Donuts does not plan to allow any of these names to be activated in the DNS until the ICANN collisions mitigation plan has been finalized, however.
So companies could find themselves paying for Sunrise names but unable to use them until some unspecified future date — if at all.