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.

Freename tries to bridge DNS and blockchain

Swiss blockchain naming startup Freename has released a service it says it hopes will help make blockchain-based naming systems easier to integrate with the traditional DNS.

It’s called NOTO, and it has launched in closed beta this week.

Freename says NOTO crawls blockchain naming systems (currently its own Freename service, Ethereum Name Service, Handshake Name Service and Unstoppable) to compile lists of domains, and then making those lists of domains available to developers either via an API or downloadable zone files that look like regular zone files.

The idea seems to be that developers using traditional DNS can stay in their comfort zone and don’t have to do the work of figuring out complexities of the blockchain. It hopes makers of browsers, search engines, DNS resolution services and such will be able to more easily add “Web3” support to their software.

Freename also reckons there’s an intellectual property protection story, with trademark owners potentially more easily able to monitor blockchain naming services for abuse.

Twitter “completely unresponsive” on clickable domains

Elon Musk’s Twitter is “completely unresponsive” to outreach about Universal Acceptance of domain names, including problems such as the lack of linkification of new gTLD domains, according to an ICANN technologist.

Speaking at an ICANN 79 Prep Week session yesterday, senior UA technology manager Arnt Gulbrandsen said the Org has been attempting to work with major platforms such as Google’s Gmail and WordPress to encourage support for newer, longer gTLDs and internationalized domain names, but with mixed results.

“What we are doing is identifying the most important, the biggest actors… testing, reaching out or contributing changes,” he said. “We don’t work equally with all. If someone’s unresponsive, then we more or less stop talking to them and hope that they grow less important as time passes.”

“This means Twitter,” he said. “Twitter is completely unresponsive.”

Twitter and other platforms such as WhatsApp have been criticized recently by the people behind gTLDs including .music and .tube for failing to “linkify” their domains. When you tweet a .music domain without the http:// prefix it will not automatically become clickable, for example.

Twitter’s cut-off point for recognizing TLDs appears to be mid-2020. The three gTLDs delegated after that — .spa, .music and .kids — do not currently linkify.

Gulbrandsen said ICANN has been getting a more encouraging response from developers within the WordPress ecosystem, where ICANN discovered that UA support relies a great deal on just three software components maintained by volunteer developers — linkify-it, phpautolink and phpmailer.

“I’m really happy about the responses from some of these obscure, open-source maintainers,” he said. “They really want to do the best for the world, and they are volunteers mostly.”

Two of the identified components currently support UA and ICANN is working with phpmailer, he said. ICANN has also been contributing UA code even further down the stack, to programming languages such as Java, Python and Ruby, he said.

Gulbrandsen’s presentation came during the ICANN 79 Prep Week session on UA, which included contributions from members of various UA working groups and focused largely on IDN and email problems. You can listen to the session in full here.

KeyTrap ‘the most devastating vulnerability ever found in DNSSEC’

A security vulnerability in the DNSSEC standard that could crash DNS resolution in software such as BIND and services such as Cloudflare and Google Public DNS has been called “the most devastating vulnerability ever found in DNSSEC”.

Named KeyTrap, it enables attackers to overwhelm a DNS resolver’s CPU for as long as 16 hours, forcing it to process up to two million times its usual load, using a single malicious DNS packet, making for a potentially crippling denial-of-service attack.

The flaw was discovered last year by Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner from ATHENE, the German National Research Center for Applied Cybersecurity, and publicly disclosed last week after vendors were given time to develop and deploy patches.

While KeyTrap has been present in DNS software for almost a quarter-century, the researchers are not aware of it being exploited in the wild.

The vulnerability is actually baked into the DNSSEC technical standards, developed in the 1990s, rather than being specific to any one implementation of the specs, according to the researchers. In fact, in order to patch the problem vendors had to break with the standard RFCs.

KeyTrap works because DNSSEC is (believe it or not) designed to avoid causing downtime when it fails, so it tries too eagerly to validate cryptographic signatures by checking all the keys available to it. Exploiting this helpfulness, an attacker could trick a resolver into eating up all its CPU resources checking huge numbers of keys.

Schulmann wrote in an article explaining the vulnerability:

Our methods show a low-resource adversary can fully attack a DNS resolver with a Denial-of-Service (DoS) for up to 16 hours with a single DNS request. Members from the 31-participant task force of major operators, vendors, and developers of DNS/DNSSEC, to which we disclosed our research, dubbed our attack ‘the most devastating vulnerability ever found in DNSSEC’.

DNSSEC is designed to mitigate the risk of DNS cache-poisoning and man-in-the-middle attacks, but because its default behavior when the crypto fails is to refuse to resolve the affected domains, it can also lead to availability problems.

It’s not uncommon for entire TLDs to fail for hours when the registry screws up a DNSSEC key rollover. The web site you’re reading right now suffered downtime a few years ago due to a DNSSEC fail at the registrar level.

The KeyTrap researchers believe about 31% of web client devices currently use DNSSEC resolvers.

ICANN insists it is working on linkification

Having been accused of ignoring the lack of universal support for new gTLDs in favor of virtue-signalling its support for multilingual domain names, ICANN has now insisted it is working on the problem.

ICANN chair Tripti Sinha said in a letter (pdf) published today that ICANN staff have been “actively engaging” with the software developer community on a “multitude of efforts” aimed at getting Universal Acceptance for all domain names.

She was responding to an October 2023 letter from .tube CEO Rami Schwartz, whose solo research last year uncovered the fact that many major app developers — including WhatsApp maker Meta — were relying on hard-coded TLD lists up to eight years old to validate domains.

This meant domains in the hundreds of TLDs that went live after November 2015 were not being detected as domains, and therefore not automatically “linkified” into clickable links, in many near-ubiquitous apps and web sites.

But Sinha insists that ICANN has been putting resources into the problem, including creating a “technical UA team” that is “actively engaging with technical organizations and communities, raising bug reports, as well as contributing open-source code where possible”.

The team has been participating in hackathons and conferences to push the UA message, she said, and has engaging in web sites such as Stack Overflow (where coders ask each other questions about tricky programming problems) to educate developers.

She named Meta and WordPress as software companies ICANN has been reaching out to directly.

“The ICANN org team has been meeting with META and reported UA related issues to them, including linkification. The team has recently also reported the issues shared by you related to more recently delegated TLDs, including .TUBE,” she told Schwartz. “META continues to look into these issues and is making progress towards resolving them.”

She also pointed out that ICANN and the ICANN-funded Universal Acceptance Steering Group held a Universal Acceptance Day last year and will conduct another this year.

UA Day is actually dozens of individual events — over 50 last year — that took place across the world over the space of a couple of months. This year’s event appears to be equally diverse, with events taking place from March to May across many locations mainly in Asia, Africa and South America.

The UASG supplies PowerPoint presentations and videos to each event to use if they wish, but the focus is very much on the substantially trickier problem of UA for internationalized domain names — domains or email addresses that use non-Latin scripts or diacritics not present in ASCII — rather than the lower-hanging fruit of getting developers to update their TLD lists more frequently.

Even though there hasn’t been a new TLD delegation for a couple of years, there were still almost 30 TLDs deleted from the DNS root last year. The number of valid TLDs changes perhaps more frequently than many developers realize.

Walking down the street somewhere, I once saw a barbershop called “Every Six Weekly”. Crap brand, certainly, but the message lodged itself in my borderline autistic nerd brain — that’s how often society expects me to get my hair cut, every six weeks.

Maybe ICANN should try something like that.

After 14 years, ICANN practices what it preaches on IDNs

Almost 14 years after the first non-Latin domain names were added to the DNS root, ICANN has finally declared itself IDN-compatible.

“ICANN staff can now send emails to and receive emails from internationalized email addresses,” the Org said in a blog post today.

“ICANN also supports short and long ASCII top-level domains in all systems, as well as ASCII-based Internationalized Domain Names (IDNs) in Punycode (A-label) in public-facing systems,” Org added. “In addition, IDNs in Unicode (U-label) work in ICANN’s public-facing systems.”

It’s the weakest brag imaginable.

ICANN is the organization that is tasked with ensuring the internet’s naming and addressing systems are interoperable globally. It’s the one organization on the planet that absolutely, by definition, has to deal with the owners of IDNs.

And yet it’s taken almost 14 years for this milestone to be reached. The first IDN TLDs — the Arabic translations of the ccTLDs of Egypt, Saudi Arabia and the United Arab Emirates — were delegated to the DNS root May 5, 2010.

As my post from that time reflects, IDN support then, even in browsers, was awful.

There have been 159 IDN TLDs in the root since the first batch (about half a dozen or so were dot-brands that have since been retired) and a great many Latin-script TLDs support IDNs at the second level.

To be fair, ICANN cannot shoulder all the blame for this tardiness. Presumably, Org uses the same off-the-shelf email systems as the rest of us, so it would have been reliant on its vendors to add the necessary support.

Today’s blog post notes that ICANN had to work with its technology partners to impress upon them the importance of IDN support and Universal Acceptance in general.

ICANN has made greater IDN adoption one of its main goals of the forthcoming next application round of the new gTLD program, part of an effort to get more registries founded in currently under-served regions.

But there are some who believe this focus on IDNs has come at the cost of ignoring Universal Acceptance issues affecting Latin-script TLDs.

Popular social networking apps — surely the most common vector for link-sharing nowadays — have been found lacking in their support for the most recently created TLDs, and some say ICANN has failed its duty to reach out to developers to school them on UA.

Last year, the CEO of .tube discovered that popular software was relying on a hard-coded list of TLDs in the Android operating system that had not been updated since November 2015, meaning the 468 TLDs that have been delegated since then would not be recognized as domains and not “linkified” when shared on apps such as WhatsApp.

It also seems that Twitter as of this week is still relying on a hard-coded TLD list that has not been updated since 2020, meaning domains in the three TLDs that have been delegated since then — .spa, .kids and .music — are not linkified.

Given how simple updating a TLD list should be, and given that somebody at ICANN presumably has the ear of somebody at Twitter or Meta or Google or wherever — Android updated its list pretty quickly when alerted to to the problem by .tube — it’s baffling to me that these problems persist in the light of ICANN’s stated focus on UA.

Dev releases free open-source TLD registry platform

A Ukrainian developer has released a free, open-source domain registry management platform that he says is compliant with ICANN standards and should be suitable for organizations that want to self-host ccTLDs or new gTLDs they apply for in the next round.

Named Namingo, lead dev Taras Kondratyuk says the software incorporates EPP, Whois and RDAP and can interface with the popular DNS servers and database management systems.

The software has been released under a standard MIT open-source license, which basically means you can do whatever you want with it with very few limitations. Kondratyuk describes the current release as a beta but said he hopes a stable version will emerge before the end of the month.

“So far, no registry or registrar has used Namingo. However, there’s interest from one ccTLD and two regional second-level domains, which plan to conduct tests soon,” he said in an email interview.

“ccTLDs can currently run Namingo without any issue, with all components being complete,” he said. “We’re just ironing out a few details for the first stable release, like making parts of panel more ‘beautiful’ or easier to work with.”

It sounds like a labor of love. Kondratyuk said he has no background in the domain industry, no plans to commercialize the software or offer paid support services. The software was scratch-built in PHP with the help of ChatGPT.

“Having worked with small hosting providers, I noticed a gap in free and open tools for managing registries or ICANN accredited registrars,” he said. “Existing solutions were either complex, infrastructure-specific, not fully supportive of gTLDs, or not genuinely free. Namingo aims to address these gaps.”

“It was developed as a community contribution,” he said. “If a company wishes to adopt it for registry services, they’re welcome to, thanks to the permissive MIT license. My role is more in line with offering guidance rather than fully engaging in a commercial venture.”

“While I’m open to providing installation support, my capacity for hosting or round-the-clock support is limited. I just hope that a company might show interest in the future and offer this service,” he said.

After the registry platform is finished, Namingo will finish off its platform for ICANN-accredited registrars too, he said.