Amazon and Google among .internal TLD ban backers

Google and Amazon have publicly backed ICANN’s plan to reserve the top-level domain .internal for private behind-the-firewall uses.

ICANN picked the string “internal” as the one that it will promise to never delegate to the DNS root, allowing network administrators and software developers to confidently use it with a lower risk of data leakage should the TLD come under a registry’s control in future.

The public comment period over its choice is coming to a close tomorrow, with a generally supportive vibe coming from the 30-odd comments submitted so far.

Notably, tech giants Amazon and Google have both filed comments backing .internal, with both companies saying that they already use the TLD extensively for internal purposes (Google in its Cloud services) and that to allow it to be delegated in future would cause big problems.

Some commenters niggled that .internal is too long, and that something like .local or .lan, both already reserved, might be better. Others wondered why strings such as .corp or .home, which are already effectively banned due to the high risk of name collisions, were not chosen instead.

Lebanon’s ccTLD going back to Lebanon after ICANN takeover

ICANN’s board of directors has voted to redelegate Lebanon’s ccTLD to the country’s local Internet Society chapter, six months after the Org took it over as an emergency caretaker.

The resolution, passed at the weekend, as usual with ccTLD redelegations does not get into any depth about the switch, other than to note IANA has ticked all the requisition procedural boxes. IANA will publish a report at a later date.

ICANN took over the ccTLD, .lb, last July after the former registry was left in limbo following the sudden death of its founder and manager. It was only the second time ICANN had made itself a ccTLD’s “caretaker”.

The board also voted at the weekend to redelegate Cameroon’s .cm, best-known in the Anglophone world for enabling .com typos purely by existing, to Agence Nationale des Technologies de l’Information et de la Communication, the local technology ministry.

Group to seek .io TLD takeover after OECD human rights ruling

A group composed of displaced Chagossians will ask ICANN to redelegate the increasingly popular .io top-level domain, according to the group’s lawyer.

The move, still in its very early stages, follows a recent ruling under the OECD Guidelines for Multinational Enterprises on Responsible Business Conduct, which mildly chastised the current registry, Identity Digital.

“The next move is domain reassignment,” lawyer Jonathan Levy, who brought the OECD complaint on behalf of the Chagos Refugees Group UK, told us. The proposed beneficiary would be “a group composed of Chagossians” he said.

.io is the ccTLD for the archipelago currently known as the British Indian Ocean Territory. It’s one of those Postel-era “Just Some Guy” developing-world delegations that pre-date ICANN.

But BIOT is a controversial territory. Originally the Chagos Archipelago, the few thousand original inhabitants were forced out by the UK government in the 1970s so the US military could build a base on Diego Garcia, the largest island.

Most of the surviving Chagossians and their descendants live in Mauritius, but have been fighting for their right to return for decades. In 2019, the UN ruled the UK’s current administration of BIOT is unlawful.

In recent years, since .io became popular, the ccTLD has become part of the fight.

The original and technically still-current registry for .io is a UK company called Internet Computer Bureau. ICB was acquired by Afilias in 2017 for $70 million. Afilias was subsequently acquired by Donuts, which is now called Identity Digital.

Corporate accounts filed by ICB name its ultimate owner as Beignet DTLD Holdings of Delaware, which appears to be a part of $2.21 billion private equity firm Ethos Capital, Identity Digital’s owner, which is co-managed by former ICANN CEO Fadi Chehadé.

None of these companies have a connection to BIOT beyond paying a local company called Sure (Diego Garcia) Limited for a mail-forwarding service. The only people believed to reside in the territory at all are US and UK military and contractors.

Levy, on behalf of the Chagossian refugees and a group of victims of cryptocurrency scams operated from .io domains, filed a complaint with the Ireland National Contact Point for the OECD Guidelines for Multinational Enterprises on Responsible Business Conduct — basically a mediation service operated by the Irish government — seeking a share of the money from .io sales and/or redelegation.

According to its most-recent public accounts, ICB had turnover of £16.4 million ($19.8 million) in 2021, up from £12.8 million ($15.5 million) in 2020, but also had absolutely horrible gross margins for a registry with only one employee.

The company had cost of sales of £15.8 million and a gross margin of 3.58%. It pays no ICANN fees and the UK government receives no cut beyond the regular corporate tax ICB pays (about £26,000 in 2021).

The OECD’s Guidelines are voluntary guidelines that countries sign up to that are meant to guide how multinational companies behave with regards human rights and so on. Enforcement seems to be relatively toothless, with national NCPs only having the power to “recommend” actions.

In fact, Afilias declined to participate in mediation and appears to have received only a mild finger-wagging in the Irish NCP’s decision (pdf), which was published in September. One of its recommendations reads:

The NCP recommends that in cases in which a product, including a digital asset, is associated with long-running disputes regarding human rights, multinational enterprises should be able to demonstrate that they have carried out human rights due diligence

Levy thinks the NCP’s decision is a big deal, saying it means the OECD has validated the Chagossians’ concerns. Coupled with the UN sanction on the UK related to BIOT, he reckons it could play in their favor in a future redelegation request.

.io domain owners shouldn’t be too worried right now, however. Redelegation takes a very long time even when the losing party agrees, and it doesn’t tend to happen without the consent of the incumbent.

ICANN takes over country’s ccTLD after Hall of Famer’s death

ICANN has assumed temporary ownership of .lb, the ccTLD for Lebanon, after the death of the man who founded the registry and managed it for 30 years.

IANA, in an unprecedented move, has made itself the “caretaker” sponsor and admin contact for .lb, according to the official record, which changed on Thursday.

The Org replaces the American University in Beirut, which as the name suggests is an American-owned university in Beirut, as sponsor and Lebanese Domain Registry as the admin.

It appears that AUB has not been involved with running .lb for a few years, having terminated its relationship with LBDR in 2020, and has told IANA that it is no longer the ccTLD’s sponsor.

AUB’s disassociation with LBDR, which appears to have been quite acrimonious, forced the registry to move onto CoCCA’s managed registry platform, where it still sits today.

Nabil Bukhalid, LBDR’s founder and a member of ISOC’s Internet Hall of Fame, had been trying to secure a permanent home for .lb for years, according to a history of the domain on the registry’s web site.

But he died unexpectedly of a heart attack while on vacation in January this year, leaving Lebanon’s domain in a bit of a limbo.

Kim Davies, head of IANA, revealed in a letter posted today (pdf) that .lb has been managed by Bukhalid’s “associates” for the last six months.

He said ICANN has approved a new “caretaker” role for IANA, and that the designation “will signal that there is an extraordinary and temporary operational situation”.

“IANA will continue to work with Bukhalid’s known associates to ensure the ongoing operation of the domain, until such time as a qualified successor is identified through a normal ccTLD transfer request process, at which time the caretaker designation will be removed,” he wrote.

.lb is believed to have fewer than 5,000 domains under management.

Bukhalid’s struggle to secure a successor played out against the backdrop of a Lebanese government that has far more important things to worry about. The country has been in a deep financial crisis since 2019, a situation exacerbated by the Covid-19 pandemic, a revolution, and one of the largest accidental non-nuclear explosions in human history.

The economic crisis was such that Bukhalid was forced to incorporate LBDR in Delaware a couple years back.

“We are establishing this designation out of an operational necessity. There appear to be no specific policies that govern a situation where the existing designated ccTLD manager no longer performs its role but there is no obvious successor,” Davies wrote.

He suggested that the ccNSO may want to consider creating a policy for this kind of scenario.

Similar situations could occur in future, I reckon, if increasingly grey and wrinkly Postel-era “Just Some Guy” ccTLD sponsors don’t make arrangements for their heirs.

Davies said in his letter that the “caretaker” designation has been used once before, for Libya’s .ly in 2004. But it’s the first time IANA has been a caretaker, and the Libya experiment went spectacularly badly.

ICANN approves ccTLD-killer policy

ICANN has formally adopted a policy that would enable it to remove ccTLDs from the DNS root when their associated countries cease to exist, raising the possibility of the Soviet Union’s .su being deleted.

Last Thursday at ICANN 75 in Kuala Lumpur, the board of directors rubber-stamped the ccNSO Retirement of ccTLDs Policy, which sets out how ccTLDs can be deleted in an orderly fashion over the course of several years.

The policy calls for ICANN and the ccTLD registry to form a “Retirement Plan” when the ccTLD’s string is removed from the ISO 3166-1 Alpha-2 standard, which defines which two-letter strings are reserved for which countries.

Strings are typically removed from this list when a country changes its name (such as Timor-Leste) or breaks up into smaller countries (such as the Netherlands Antilles).

The Retirement Plan would see the ccTLD removed from the root five years after ISO made the change, though this could be extended if the registry asks and ICANN agrees.

In February, I set out the case for why the policy may allow ICANN to retire .su, the thriving ccTLD for the Soviet Union, three decades after that nation was dismantled.

DNSSEC claims another victim as entire TLD disappears

A country’s top-level domain disappeared from the internet for many people yesterday, apparently due to a DNSSEC key rollover gone wrong.

All domains in Fiji’s ccTLD, .fj, stopped resolving for anyone behind a strict DNSSEC resolver in the early hours of the morning UTC, afternoon local time, and stayed down for over 12 hours.

Some domains may still be affected due to caching, according to the registry and others.

The University of the South Pacific, which runs the domain, said that it had to contact ICANN’s IANA people to get the problem fixed, which took a while because it had to wait for IANA’s US-based support desk to wake up.

IANA head Kim Davies said that in fact its support runs 24/7 and in this case IANA took Fiji’s call at 2.47am local time.

Analyses on mailing lists and by Cloudflare immediately pointed to a misconfiguration in the country’s DNSSEC.

It seems Fiji rolled one of its keys for the first time and messed it up, meaning its zone was signed with a non-existent key.

Resolvers that implement DNSSEC strictly view such misconfigurations as a potential attack and nix the entire affected zone.

It happens surprisingly often, though not usually at the TLD level. That said, a similar problem hit thousands of Sweden’s .se domains, despite the registry having a decade’s more DNSSEC experience than Fiji, last month.

Domain Incite had a similar problem recently when its registrar carried on publishing DNSSEC information for the domain long after I’d stopped paying for it.

UPDATE: This post was updated with comment from IANA.

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?

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”.

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!

.gov TLD quietly changes hands

The .gov TLD used exclusively by governmental entities in the US has quietly changed managers.

On Friday, the IANA records for .gov changed from the General Services Administration to the Cybersecurity and Infrastructure Security Agency.

It was not unexpected. CISA announced the move in March.

But it’s less clear how the change request was handled. The ICANN board of directors certainly didn’t have a formal vote on the matter. IANA has not released a redelegation report as it would with a ccTLD.

CISA intends to make .gov domains more widely available to agencies at the federal, state, city and tribal level, and reduce the price to free or almost free.

Verisign currently manages the technical aspects of the domain, for $400 per domain per year.