Ukraine asks ICANN to turn off Russia’s internet, but it’s a bad idea

Ukraine has asked ICANN to take down Russia’s top-level domains.

Andrii Nabok, the Ukrainian official on ICANN’s Governmental Advisory Committee made the request, asking the Org to “Revoke, permanently or temporarily, the domains .ru, .рф and .su” in a widely circulated email last night.

He also asked for DNS root servers in Moscow and St Petersburg to be shut down, and said he’s written to RIPE NCC to request IP addresses issued to Russian organizations to be withdrawn.

The request came on the fifth day of the Russian invasion, amid widespread, swingeing international sanctions targeting the Russian economy and high net worth individuals.

Accusing Russia of “war crimes”, Nabok wrote:

These atrocious crimes have been made possible mainly due to the Russian propaganda machinery using websites continuously spreading disinformation, hate speech, promoting violence and hiding the truth regarding the war in Ukraine. Ukrainian IT infrastructure has undergone numerous attacks from the Russian side impeding citizens’ and government’s ability to communicate.

Moreover, it’s becoming clear that this aggression could spread much further around the globe as the Russian Federation puts the nuclear deterrent on “special alert” and threatens both Sweden and Finland with “military and political consequences” if these states join NATO. Such developments are unacceptable in the civilized, peaceful world, in the XXI century.

Reaction in the community has been more mixed than I would have expected, but I think on balance more people are saying that turning off .ru et al would be a terrible idea, and I’m basically with that majority.

While there’s no doubt that Russia is spreading a lot of misinformation, I’m not sure there’s a direct, clear, demonstrable causal link between propaganda published on .ru domains and the missiles currently raining down on Kyiv that could be remedied by deleting a few lines from a database.

I’ve no doubt ICANN now has a painful decision to make, but I don’t think ICANN is the place to achieve this kind of goal and I think ICANN agrees with me.

We don’t want those clowns deciding what can and can’t be published on the internet, trust me.

Not even in the extraordinary circumstances we find ourselves in today.

ICANN is not competent enough, smart enough, or ethical enough to have that kind of power.

It is smart enough to accept its own limitations, however, and it has a strong enough sense of self-preservation to know that to accept Ukraine’s demands would be to sign its own death warrant.

ICANN only has power, and its execs only pull in the big salaries, because it has the consensus support of the internet community.

For 20 years outsiders, such as the ITU and more lately blockchain projects, have sought to chip away at that consensus and replace the multistakeholder model with multilateralism or crypto-based wish-thinking.

Turning off a nation’s TLD would play exactly into the narrative that DNS oversight is dangerously centralized, dangerously Americanized, and ripe for replacement.

That could not only lead to the death of ICANN but also the death of the open, interoperable, international internet.

As much as I support sanctions against Russia, and have nothing but respect and admiration for the people of Ukraine, I fear this is an ask too far.

Maybe now’s the time for ICANN to start dismantling the Soviet Union

Like I’m sure a great many of you, I spent much of yesterday listening to the news and doom-scrolling social media in despair, anger and helplessness.

War has returned to Europe, with Vladimir Putin’s Russia yesterday invading Ukraine on a flimsy pretext, in an apparent effort to begin to recreate the former Soviet Union.

I watched r/ukraine on Reddit, as its number of subscribers increased by tens of thousands in a matter of hours, with people from all over the world wondering what they could do to help, from volunteering to literally take up arms to hollow if well-meaning virtue-signalling.

Can I volunteer for the Ukrainian army? I live in Japan and can’t speak the language, does that matter?

Slava Ukraini!

It got me thinking: is there anything the domain industry or ICANN community can do? Is there anything I can do?

The only thing I could think of was to run this idea up the flagpole and see if anyone sets fire to it:

Maybe now’s the time for ICANN to start dismantling the Soviet Union.

It may sound ludicrous. The Soviet Union hasn’t existed outside Putin’s fantasies since 1991.

But it’s alive and well in the DNS, where the top-level domain .su has somehow managed to survive the death of its nation, evade any efforts to have it removed, and stick around in the root for over 30 years.

It currently has over 100,000 registered domains.

I’m not suggesting for a second that all of these domains were registered by people who support the return of the USSR, or are even aware of the connection, but it is the ccTLD of choice for sites like this gung-ho propaganda rag, and the Donetsk People’s Republic, the breakaway Ukrainian region.

Whenever I’ve asked people with better in-depth knowledge of ccTLD policy than me for an explanation of why .su continues to exist, despite not having a nation to represent, I generally get a lot of hand-waving and mumbling about a “lack of political will”.

Maybe there’s a political will now, if not at ICANN Org then perhaps in the ICANN community.

My understanding, based on a deep-dive through the public record, is that it might be possible to have .su deleted — the word ICANN uses is “retired” — but the rules are arguably open to interpretation.

A bit of background first

ICANN’s rules concerning ccTLDs are a bit like the UK constitution — they’re not written down in any one document, but have rather evolved over the years through a combination of habit, convention, case law and pure making-it-up-on-the-spot.

ICANN, and IANA before it, “is not in the business of deciding what is and what is not a country”. It has always deferred to the International Organization for Standardization, which maintains a list of names and corresponding country-codes called ISO 3166-1.

If a country or territory appears on the 3166-1 list, its corresponding “alpha-2” code is eligible to become a ccTLD.

SU was listed on 3166-1, the same as any other country, until September 1992, when it was broken up into 15 names and codes corresponding to the 15 former Soviet nations. Russia got RU and Ukraine got UA, for examples, and their ccTLDs are .ru and .ua.

SU was then given a “transitionally reserved” status by the ISO, which basically means it’s due to be phased off the list altogether (albeit not for 50 years) and organizations are discouraged from using it.

In corresponding ccTLDs, every string on the “transitionally reserved” list has either transitioned to a new ccTLD (such as East Timor’s .tp becoming Timor-Leste’s .tl) or split into a collection of new ccTLDs (such as the break-up of the Netherlands Antilles).

Since ICANN took over the root, these and other transitions typically happen with the consent of the local government and the local registry. But the Soviet Union dissolved long before ICANN existed, it doesn’t have a government, and the registry is in no hurry to give up its asset, which is a bit of a money maker.

ICANN stated its intention to retire .su as early as 2003, and the earliest archived IANA record, from 2006, said it was “being phased out”.

It launched a brief consultation on the retirement of ccTLDs in 2006, which prompted a flood of comments from outraged .su supporters.

The following year, there were face-to-face talks between ICANN and the two Moscow companies running .su at the time — the Foundation for Internet Development (FID) and Russian Institute for Public Networks (RIPN).

IANA’s Kim Davies, who now heads the division as an ICANN VP, blogged in 2007, partly in response to these comments, that .su had a chance to remain delegated:

To retain .SU, under current policy they would need to successfully apply for the code to be re-instated into the ISO 3166-1 standard, either as a regular two-letter country code, or as an “exceptionally reserved” code like UK and EU.

The “exceptionally reserved” list is another subdivision of ISO 3166-1. It currently includes four codes that are also ccTLDs — .ac for Ascension Island, a UK territory, .uk itself, and the European Union’s .eu.

The fourth is .su, because FID somehow managed to persuade the ISO 3166 Maintenance Agency to get SU on the list, reversing its 50-year sentence on the transitional list, in 2008. It appears to be the only example of a private, non-governmental, non-UN entity requesting and obtaining a special listing.

There’s been very little public discussion about .su’s fate since then. My suspicion is that it fell off the radar when ICANN CEO Paul Twomey, who made ccTLD relations a cornerstone of his administration, left the Org in 2009.

Or it could be that that the “exceptionally reserved” status was enough to satisfy IANA’s eligibility criteria. But there are several reasons why that might not be the case.

In Davies’ 2007 blog, post he said: “There are other issues that will need to be addressed for .SU to be a viable ccTLD designation, but recognition by the appropriate standard is a prerequisite.”

IANA currently has a web page in which it lays out seven ways a TLD can get into the root. This is what it says about exceptionally reserved strings:

Eligible under ICANN Board Resolution 00.74. This resolution provides for eligibility for domains that are not on the ISO 3166-1 standard, but that the Maintenance Agency deems exceptionally reserved, and requires that the Agency “has issued a reservation of the code that covers any application of ISO 3166-1 that needs a coded representation in the name of the country, territory, or area involved”. There is currently (as of June 2013) only one code eligible under these requirements, “EU” for the European Union.

The cited ICANN board resolution, now incorporated into IANA precedential law, dates from September 2000. It’s the resolution that hacked historical IANA practice in order to set the groundwork for eventually levering .eu into the root.

But the relevant part here is where IANA explicitly rules out any exceptionally reserved string other than EU meeting the requirements to be a ccTLD as of 2013. SU’s ISO 3166-1 status has not changed since 2008.

RIPN and FID explicitly acknowledged this in a joint letter (pdf) to ICANN then-CEO Paul Twomey in 2007. In it, they wrote:

we understand that should ISO-3166/MA add the two letter code “SU” to the exceptionally reserved or indeterminately reserved ISO3166-1 list will not be sufficient to clarify the status of .SU as current ICANN/IANA policies require a venue in which legality of actions can be determined.

To paraphrase: being on the list ain’t no good if you got no country.

They said that if ICANN went ahead and retired .su anyway, they would like 10 to 15 years to transition their registrants to alternative TLDs.

Which handily brings me to now

There has never been a formal community-agreed ICANN policy on retiring ccTLDs, until now.

By happy coincidence, the ccTLD Name Supporting Organization recently finished work on such a policy. It came out of public comment a few weeks ago and will next (I was going to write “soon”, but you know?) come before the ICANN board of directors for consideration.

The proposed policy (pdf) conspicuously avoids mentioning .su by name and seems to go out of its way to kick the can on .su’s potential retirement.

The silence is deafening, and the ambiguity is claustrophobic.

It defines ccTLDs as:

• 2-letter ccTLDs corresponding to an ISO 3166-1 Alpha-2 Code Element (the majority of ccTLDs).
• 2-letter Latin ccTLDs not corresponding to an ISO 3166-1 Alpha-2 Code Element
• IDN ccTLDs as approved by ICANN

The second bullet point is accompanied by a footnote that explains it’s referring to the “exceptionally reserved” codes UK, AC and EU, three of the four ccTLDs on the ISO’s exceptional list.

The ccTLDs .uk and .ac which refer to exceptionally reserved codes UK and AC are grandfathered as ccTLDs and .eu, which corresponds to the exceptionally reserved code EU, was delegated under the relevant ICANN Board resolution from September 2000

There’s no mention of SU, the fourth.

Under the proposed policy, the ball would start rolling on a possible retirement whenever a “triggering event” happens. The relevant trigger for .su (and .uk, .eu and .ac) is the ISO making a change — seemingly any change — to its 3166-1 listing.

IANA, referred to in the policy as the IANA Functions Operator or IFO, would then have to decide whether the change warranted initiating the retirement process, which would take at least five years.

As is so often the case in ICANN policy-making, the difficult decisions seem to have been punted.

Only one ccTLD operator filed a public comment on this proposed policy — it was RIPN, operator of .su. While generally supportive, it worried aloud that triggering events prior to the approval of the policy should not count. Its triggering events were in 2008 and the 1990s, after all.

The policy’s creators again ambiguously kicked the can:

The [Working Group] believes the applicability of the Policy to existing situations or those emerging before the proposed Policy becomes effective is out of scope of its mandate. For situations prior to this Policy coming into force, responsibility lies with the IFO to create a suitable procedure. The WG suggests that such a procedure could be based on and anticipates the proposed Policy.

So… does ICANN get to apply the policy retroactively or not?

My overall sense is that the .su situation, which the record shows was certainly on the minds of the ccNSO during the early stages of the policy-development process, was considered too difficult to address, so they took the ostrich approach of pretending it doesn’t exist.

The .su registry seems to think it’s safe from enforced retirement, but it doesn’t seem to be absolutely sure.

In conclusion

I think the record shows that .su doesn’t really deserve to exist in the DNS, and that there’s an opportunity to get rid of it. ccTLDs are for countries and territories that exist and the Soviet Union hasn’t existed for three decades.

IANA rules don’t seem to support its existence, and upcoming policy changes seem to give enough wiggle room for the retirement process to be kicked off, if the will is there to do so.

It would take years, sure.

Would it help stop innocent Ukrainians getting gunned down in the street this week? No.

Would it be more than simple virtue signalling? I think so.

And if not, why not just do it anyway?

In a world where an organization like UEFA considers Russia too toxic for poxy football match, what would it say about an organization that allows the actual Soviet Union’s domain to continue to exist online?

Registrar hit with second porn UDRP breach notice this year

A Chinese registrar group has been accused by ICANN of shirking its UDRP obligations for the second time this year.

ICANN has put Hong Kong-based DomainName Highway on notice that is in breach of its contract for failing to transfer the domain 1ockheedmartin.com to defense contractor Lockheed Martin.

The domain is a straightforward case of typosquatting, with the initial L replaced with a numeral 1. At time of writing, it still resolves to a page of pornographic thumbnail links, despite being lost in a UDRP case January 4.

Under UDRP rules, registrars have 10 days to transfer a UDRP-losing domain to the trademark owner, unless a lawsuit prevents it.

The circumstances are very similar to a breach notice ICANN issued against ThreadAgent.com over a case of BMW’s brand being cybersquatted with porn last month.

Both ThreadAgent and DomainName Highway appear to be part of the XZ.com, aka Xiamen DianMedia Network Technology Co, which is based in China but has about 20 accredited registrars based in Hong Kong.

DomainName Highway has about 30,000 gTLD domains under management.

Costa Rica’s only registrar gets terminated

Costa Rica no longer has any in-country accredited registrars, after ICANN terminated Toglodo for non-payment of fees.

ICANN told the company last week that its accreditation is terminated effective February 23.

It seems Toglodo owed ICANN thousands of dollars in past-due fees. The Org says had been chasing it for money since at least March last year, but had not managed to make contact.

The registrar once had a few thousand gTLD domains under management, mostly .coms, but that’s dwindled to almost nothing recently. Whatever domains remain, ICANN will attempt to transfer to another registrar.

ICANN stuck between Ukraine and Russia in time zone debate

As the world waits nervously to see whether Russia’s weeks-long troop build-up on the Ukrainian border will result in an invasion, ICANN is embroiled in an infinitely more trivial conflict between the two nations.

As well as overseeing domain names, IP addresses and protocol numbers, a decade ago ICANN took over the time zone database that most of the world’s computers rely on to figure out what the correct time is or was.

The Time Zone Database or tzdb has been hosted by ICANN’s IANA unit since 2011, when it stepped in to relieve the previous host, which was being badgered in court by astrologers.

It’s managed and regularly updated — such as when a country changes its time zone or modifies its daylight savings practices — by Paul Eggert of the University of California.

While it’s apolitical, governed by IETF best practice, it occasionally finds itself in the firing line due to political controversies.

In recent years, a recurrent controversy — which has raised its head again this month in light of the current border crisis — has been the spelling of the Ukrainian capital city.

It has long been rendered in English as “Kiev”, but that’s the Latin-script transliteration of the Russian-Cyrillic spelling Киев, rather than the Ukrainian-Cyrillic spelling, Київ, which is transliterated as “Kyiv”.

With tensions between Russia and Ukraine intensifying since the 2014 annexation of Crimea, Ukraine has for years appealed to the international community to change its “painful” spelling practices.

The Ukrainian Ministry of Foreign Affairs in 2019, part of its #CorrectUA and #KyivNotKiev campaigns, described the situation like this:

Under the Russian empire and later the Union of Soviet Socialist Republics (USSR), Russification was actively used as a tool to extinguish each constituent country’s national identity, culture and language. In light of Russia’s war of aggression against Ukraine, including its illegal occupation of Crimea, we are once again experiencing Russification as a tactic that attempts to destabilize and delegitimize our country. You will appreciate, we hope, how the use of Soviet-era placenames – rooted in the Russian language – is especially painful and unacceptable to the people of Ukraine.

Many English-language news outlets — including the Associated Press and Guardian style guides, the BBC, New York Times and Wall Street Journal — have since switched to the “Kyiv” spelling, though many are still using “Kiev”.

The US and UK governments both currently use “Kyiv”. Wikipedia switched to “Kyiv” in 2020. ICANN’s own new gTLD program rules, which draw on international standards, would treat both “Kiev” and “Kyiv” as protected geographic names.

My Windows computer used “Kyiv”, but the clock on my Android phone uses “Kiev”.

The tzdb currently lists Kyiv’s time zone as “Europe/Kiev”, because it follows the English-language consensus, with the comments providing this October 2018 explanation from Eggert:

As is usual in tzdb, Ukrainian zones use the most common English spellings. For example, tzdb uses Europe/Kiev, as “Kiev” is the most common spelling in English for Ukraine’s capital, even though it is certainly wrong as a transliteration of the Ukrainian “Київ”. This is similar to tzdb’s use of Europe/Prague, which is certainly wrong as a transliteration of the Czech “Praha”. (“Kiev” came from old Slavic via Russian to English, and “Prague” came from old Slavic via French to English, so the two cases have something in common.) Admittedly English-language spelling of Ukrainian names is controversial, and some day “Kyiv” may become substantially more popular in English; in the meantime, stick with the traditional English “Kiev” as that means less disruption for our users.

Because the tzdb is incorporated in billions of installations of operating systems, programming frameworks and applications worldwide, a conservative approach to changes has been used for compatibility reasons.

In addition, the spelling in the database is not supposed to be exposed to end users. Developers may use tzdb in their code, but they’re encouraged to draw on resources such as the Unicode Common Locale Data Repository to localize their user interfaces.

As Eggert put it on the tzdb mailing list recently “the choice of spelling should not be important to end users, as the tzdb spelling is not intended to be visible to them”.

Based on past changes, it seems that “Kyiv” could one day before too long supplant “Kiev” in the tzdb, if the current political status quo remains and English-speaking nations increasingly support Ukraine’s independent sovereignty.

But if Russia should invade and occupy, who knows how the language will change?

This article has been part of an irregular series entitled “Murphy Feels Guilty About Covering Incredibly Serious Current Events With A Trivial Domain Angle, But He Writes A Domain Blog So Cut Him Some Slack FFS”.

Greek .eu domains to be deleted

EURid has started warning registrants that their Greek-script .eu domains will be deleted this year.

The names will no longer work after November 14, the company said yesterday.

It’s part of the registry’s three-year plan to phase out mixed-script internationalized domain names, which are considered poor security practice.

The affected domains are Greek-script IDN.eu names, not IDN.IDN names using the Greek-script .ευ.

.ευ was introduced in 2019, after an amusingly Kafkaesque, yet typically ICANN, decade-long effort to crowbar the ccTLD through its IDN Fast Track rules.

Because EURid had been accepting Greek-script second-level names under its base Latin .eu domain for some time, it grandfathered existing registrants by “cloning” their .eu names into .ευ, albeit with only a three-year lifespan.

There were only 2,694 .ευ domains registered at the end of 2021, so one must assume that the number of domains on the deleting list must be smaller.

“It’s not our fault!” — ICANN blames community for widespread delays

ICANN may be years behind schedule when it comes to getting things done on multiple fronts, but it’s the community’s fault for making up rubbish policies, bickering endlessly, and attempting to hack the policy-making process.

That’s me paraphrasing a letter sent last week by chair Maarten Botterman to the Registries Stakeholder Group, in which he complained about the community providing “ambiguous, incomplete, or unclear policy recommendations”.

RySG chair Samantha Demetriou had written to Botterman (pdf) in December to lament the Org and board’s lack of timely progress on many initiatives, some of which have been in limbo for many years.

Policies and projects related to Whois, new gTLDs and the Independent Review Process have been held up for a long time, in the latter case since 2013, she wrote, leading to community volunteers feeling “disempowered or discouraged”.

As I recently reported, ICANN has not implemented a GNSO policy since 2016.

The lack of board action on community work also risks ICANN’s legitimacy and credibility, Demetriou wrote.

But Botterman’s response (pdf), sent Thursday, deflects blame back at the community, denying that the delays are “simply because of failure at the level of the organization and Board.”

He wrote:

we need to continue to find our way forward together to address the challenges that affect the efficiency of our current decision-making processes, including, for example, ambiguous, incomplete, or unclear policy recommendations, the relitigation of policy issues during implementation, and the use of the review process to create recommendations that should properly be addressed by policy development

In other words, the community is providing badly thought-out policy recommendations, continuing to argue about policy after the implementation stage is underway, and using community reviews, rather than the Policy Development Process, to create policy.

The RySG, along with their registrar counterparts, put their concerns to the board at ICANN 72 in October, warning of “volunteer burnout” and a “chilling effect” on community morale due to board and Org inaction.

At that meeting, director Avri Doria presented staff-compiled stats showing that across five recent bylaws-mandated community reviews (not PDPs), the board had received 241 recommendations.

She said that 69% had been approved, 7% had been rejected, 18% were placed in a pending status, and 6% were “still being worked on”.

CEO Göran Marby provided a laundry list of excuses for the delays, including: reconciling differing community viewpoints, the large number of recommendations being considered, the potential for some recommendations to break ICANN bylaws, sensitivity to the bottom-up nature of the multi-stakeholder process, lack of staff, and the extra time it takes to be transparent about decision-making.

Just this week, ICANN has posted eight job listings, mostly in policy support.

In his letter last week, Botterman pointed to a “Prioritization Framework”, which is currently being piloted, along with further community conversations at ICANN 73 next month and a “thought paper” on “evolving consensus policies”.

Because why fix something when you can instead create another layer of bureaucracy and indulge in more navel-gazing?

Surprising nobody, Verisign to raise .com prices again

Verisign has announced its second consecutive annual price increase for .com domain names.

The wholesale registry fee for .com names will rise from $8.39 to $8.97 on September 1 this year, an extra $0.58 for every new or renewing domain, of which there are currently over 160 million.

Verisign announced the move, which was expected, as it announced a 2021 profit of $785 million and a 65.3% operating margin.

CEO Jim Bidzos, speaking to analysts, played down the impact of the increases on .com registrants, pointing out that .com prices were frozen under the Obama administration and have only gone up once before, last year, since 2012.

“This is the second wholesale price increase for COM since January of 2012,” he said. “So, if you look back over the last 10 years, that translates into a cost increase of only 1.3% CAGR over the last ten and a half years actually.”

The current .com contract, signed off by the Trump administration and ICANN, allows for two more 7% annual price increases, excluding the just-announced one, but Bidzos would not say whether Verisign plans to exercise those options.

If it does (and it almost certainly will) it would raise the price to $10.26, where it would stay until at least October 2026, he said.

“We believe .com continues to be positioned competitively,” he said.

It’s still basically free money for Verisign, which saw strong fourth-quarter and full-year 2021 results.

The company yesterday reported revenue of $1.33 billion for 2021, up 4.9%, with net income of $785 million, down from $815 million. The operating margin was 65.3%, compared to 65.2%.

For the fourth quarter, revenue was up 6.3% to $340 million, with net income of $330 million compared to $157 million. Operating margin was 65.3%, compared to 63.9%.

For 2022, the company is guiding for revenue of between $1.42 billion and $1.44 billion, based on the price increases and predicted unit growth of between 2.5% and 4.5%. The operating margin is expected to be between 64.5% and 65.5%.

Bidzos also addressed the controversial .web gTLD, which it won at auction but has been unable to launch due to legal action pursued by rival bidder Afilias/Altanovo.

An Independent Review Process panel recently threw a decision about .web back at ICANN, which is now considering Afilias’ allegations of wrongdoing at the board level.

“ICANN looks to be moving forward with making the decision on the delegation of .web, and we will be monitoring their process,” Bidzos said. He said that Verisign has not budgeted for any revenue or costs from .web in 2022.

That’s probably wise. Afilias recently told us that it has not stopped fighting against Verisign’s .web win.

Is the .sucks mass-cybersquatting experiment over?

The Everything.sucks experiment is mass-cybersquatting .sucks domains may be over and done with.

Thousands of .sucks domains have been deleted in a huge junk drop, newly created domains at Everything.sucks’ registrar of choice have dried up, and there have been no new UDRP cases filed in months.

Everything.sucks, you may recall, is a wiki-style web site where thousands of famous brands and public figures have pages populated by content scraped from third-party sites discussing, on the rare occasion when the scraping works, how terrible they are.

When the site emerged in 2020, it was a redirect destination for around 2,000 .sucks domains that exactly matched those brands. You typed jackdaniels.sucks into your browser, you wound up at the Jack Daniels page at Everything.sucks.

Various attempts were made at monetizing these names by persuading the brand owners to purchase or transfer them for fees measured in the hundreds, or more usually thousands, of dollars.

The domains were registered to a Turks & Caicos company called Honey Salt and a likely fictitious individual named Pat Honeysalt or Pat Collins. The registrant has fought 21 UDRP cases, most of which it lost, since July 2020.

There hasn’t been a UDRP complaint filed against a .sucks domain since November 2021, and this may be because most of Honey Salt’s domains were only registered for one year and have since expired and dropped.

Registry transaction reports filed with ICANN by .sucks registry Vox Populi show the registrar Rebel.com — Vox’s sister company and Honey Salt’s registrar of choice — deleted 2,179 .sucks domains in September 2021.

That’s very close to the 2,184 one-year adds Rebel recorded in June 2020.

The most likely interpretation of this data, in my view, is that it’s Honey Salt’s first junk drop — the company let the domains go on expiry having failed to sell them to the brand owners and failed to convince UDRP panels that it wasn’t cybersquatting.

At least couple thousand more .sucks domains were registered via Rebel over the year to June 2021, most likely to Honey Salt, but since then the registrar has been selling no more than two or three new .sucks domains per month.

It looks like Honey Salt stopped buying .sucks domains in bulk several months ago.

And zone files show that the total number of active .sucks domains has continued to decline by the thousands since Vox’s last transaction report, from an August 2021 peak of over 13,000, to fewer than 9,000 today.

If these trends continue, it looks like the experiment in mass cybersquatting might be over by the third quarter, when Honey Salt’s last remaining .sucks domains drop.

UDRP panelists and yours truly have speculated that Vox/Rebel and Honey Salt are probably affiliated, because the registry/registrar are the only parties that stood to benefit from Everything.sucks’ monetization techniques, but Vox has denied a connection.

At ICANN, you can have any registrar you want, as long as it begins with A

Want to find a registrar based in your home country, or in a friendlier foreign jurisdiction? Don’t rely on ICANN to help.

A recent outcome of the Org’s information transparency car crash is a registrar search engine that only returns filtered results where the registrar’s name begins with the letter A.

The search engine allows users to search for registrars by name, IANA number or the country/territory where the registrar is based. Results can also be filtered alphabetically.

But it’s broken.

If you’re looking for a local registrar, or an overseas registrar, perhaps because you’re concerned about the legal jurisdiction of the company before you register a domain, you might expect the handy drop-down countries menu to bear fruit.

Say you’re looking for an Irish registrar. You select “Ireland” from the drop-down:

And the results come back:

Oh. According to these results, there are no ICANN-accredited registrars based in Ireland.

But I notice the letter A is highlighted. Perhaps it’s only showing me the registrars beginning with A.

Are there any Irish registrars beginning with B? I’m sure I’ve heard of one, but the name escapes me. I click B:

Oh. It’s showing me registrars beginning with B, but they’re not all Irish. The search engine has cleared my original filter.

With B still selected, I filter again by country, and now I’m looking at an empty result set again. There are no Irish registrars beginning with A, ICANN is telling me again.

There also doesn’t appear to be a way to filter for registrars that begin with numerals or special symbols, so the likes of 123reg and 101domain appear to be fresh out of luck.

This search engine appears to have been live for about a year, replacing the old flat list, which appears to have been deleted, because that’s how ICANN rolls nowadays.

I don’t know whether it’s been broken the whole time it’s been live, nor whether ICANN knows it’s broken.

Perhaps nobody uses it. It does appear to be the only way to find accredited registrars by country on the ICANN or IANA web sites.

UPDATE Feb 4, 2022: within approximately seven hours, one of the major bugs reported in this post had been fixed. That’s what I call tech support!