RDRS usage hits new low

ICANN’s Registration Data Request Service was used less often in October than in any other month since it launched a year ago, according to the latest statistics.

There were 131 requests for private Whois data in the month, down from the previous low of 141 recorded in May and September’s 189, the monthly report published by ICANN shows.

There were 98 closed requests — another new low — and the mix of granted/refused requests tilted more towards approval than usual, with almost 35% of requests being approved versus 56% denied.

While it took on average 3.41 days for requests to be approved, the average time for denial was an incredible 41.96 days.

Three new registrars joined the voluntary pilot program in October, giving RDRS coverage of 60% of registered gTLD domain names.

The monthly report breaks down the geographic location of requestors and the requestor type for the first time, showing that the US was by far the biggest, followed by the UK, France and Brazil, with American IP owners and law enforcement most likely to request data.

Twitter clone Bluesky has one feature domain people should like

People are abandoning Twitter, and they seem to be largely gravitating towards a very similar clone that has one feature that should appeal to domain owners.

Bluesky, available at bsky.app, was set up by Twitter founder Jack Dorsey five years ago. It’s adding about a million users a day right now, rapidly approaching the 20 million mark today.

Anecdotally, it seems its surge in popularity has come about due to widespread dissatisfaction with Twitter’s miserable direction under Elon Musk’s leadership, particularly due to his role in the recent US presidential election.

So I thought I’d jump on the bandwagon and grab my Bluesky screen name before somebody else could.

But it turns out I didn’t need to. Bluesky has a feature that allows you to use your domain as your username, and it’s verified so nobody else can claim it.

You need to simply add a short TXT record to your DNS settings, which Bluesky can check. If you’re reading this blog, chances are you already know how to do this. It takes about two minutes.

So I’m domainincite.com on the platform and I’ll be posting there alongside Twitter, LinkedIn and Facebook from now on. Feel free to join me.

Verisign gets eight more years running the root

Verisign and ICANN have renewed their deal that sees Verisign run the DNS root, according to the company.

Verisign said the Root Zone Maintainer Agreement was renewed on October 20 for another eight-year term.

The RZMA is basically a technical services contract under which Verisign updates and publishes the root zone file (basically a list of TLDs and their nameservers) according to ICANN’s instructions. All the other root zone operators mirror that file.

It’s the first renewal since ICANN secured its independence from the US government in 2016, but Verisign and its predecessors have been managing the root since 1993.

The deal is separate from Verisign’s contracts to run .com and .net.

Twitter now up-to-date on linkification

Twitter appears to have dragged itself into the 2020s with the linkification function of its service, after years of complaints.

On the web version of its service at least, Twitter now correctly makes domains in all the newest TLDs into clickable links automatically, with no http:// prefix required.

This means users are able to share clickable domains in .spa, .kids and .music, the three gTLDs delegated after Twitter’s previous delegation cut-off point of around April 2020.

It’s not clear to me when the change was made, or whether the fix also applies to the Twitter app on Android or iOS devices.

It’s equally not clear whether the change is due to Twitter’s own engineering, or whether a third-party library somewhere in its software stack was updated independently.

Regardless, it’s good news for the registries and registrants concerned, particularly DotMusic, whose .music gTLD goes on sale today.

Twitter came in for criticism from an ICANN engineer earlier this year for ignoring outreach efforts on Universal Acceptance, the program that aims to get all TLDs functioning properly across all software platforms.

Meta, owner of Facebook, Instagram and Whatsapp, is understood to have been far more responsive, following complaints last year from the .tube registry operator.

ICANN hit by DDoS attack

If you noticed ICANN’s web site acting sluggishly or failing to respond at all last week, now you know why.

The site at icann.org was hit by a distributed denial of service attack on September 3 through September 4, according to a brief statement on the Org’s now-functional site.

ICANN identified a Distributed Denial of Service (DDoS) event that occurred on www.icann.org on 3 Sept. 2024. The situation was mitigated and service to ICANN’s website was restored on 4 Sept. 2024.

No additional information has yet been released on the size, duration or possible motivations behind the attack.

It’s the first security incident ICANN has judged significant enough to publicly disclose in over two years.

Crowdstrike screw-up took down ICANN’s email

The domain name industry seemed to have dodged a bullet when it came to last Friday’s devastating worldwide computer outage, but it emerged over the weekend that at least one ear was grazed.

ICANN revealed late Friday that its email systems, hosted by an external provider, were affected by the bug, which saw millions of Windows endpoints bricked by a dodgy patch from security firm Crowdstrike.

At 2035 UTC, ICANN said: “ICANN is having email issues and we may not receive your email. ICANN’s external email vendor has been affected by today’s global IT outages”.

But by 0121 UTC Saturday, it reported: “ICANN’s email service has been restored and all email-dependent services have resumed.”

Given that ICANN often uses 2359 UTC as a cut-off point for things like public comment submissions, which are received via email, it’s easy to see how the lack of an inbox over that window could have caused some minor headaches on a different day.

I’m not aware of reports of any serious incidents in the wider domain space caused by the Crowdstrike bug. DNS resolution services do not typically rely upon the uninterrupted availability of Windows endpoints.

Unstoppable Domains goes down after domain hijack

Unstoppable Domains, operator of the blockchain-based alternative naming system, has had its domain hijacked and is warning customers to be wary of further scams and attacks.

“Unstoppabledomains.com has been subject to an attack. Do NOT open emails from @unstoppabledomains.com or use the website until further notice,” the company tweeted on Twitter.

🚨 Community and Partners take note! https://t.co/NRTKqQHYtu has been subject to an attack. Do NOT open emails from @unstoppabledomains.com or use the website until further notice. @squarespace @SquarespaceHelp pic.twitter.com/eynrlcadbR

— unstoppable.crypto (@unstoppableweb) July 12, 2024

Company founder Matthew Gould suggested in a tweet that the company’s registrar account, at SquareSpace, has been compromised. He said he suspected it may be related to SquareSpace’s acquisition of Google Domains.

He said the attackers are already sending out “fake emails” and that he expects them to set up a fake web site at the .com domain. It does not currently resolve from where I’m sitting.

The Whois record shows that the domain was updated shortly after 0200 UTC today and then again just a few minutes ago.

WhatsApp now linkifying new gTLDs, but…

All URLs using new gTLD domains are now being automatically linkified by WhatsApp, according to the registry manager who’s been pushing for greater support from the major social networks.

Rami Schwartz of Latin American Telecom, the .tube registry, says that WhatsApp on Android devices is now making all new gTLD domains clickable even without the http:// prefix, but that the app on Apple devices has not yet caught up.

Schwartz discovered last year that WhatsApp did not support any gTLD delegated after November 2015, apparently due to the app relying an outdated hard-coded list of gTLDs in Android.

While the list was quickly updated, it’s taken a while for support to trickle down to devices.

Schwartz credited the WhatsApp team at Meta in the UK and ICANN technology specialist Arnt Gulbrandsen with getting the linkification support accomplished. He said he hopes iOS support will come soon.

.home, .mail and .corp could get unbanned

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.