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.

.tube registry claims victory in linkification fight

Latin American Telecom, the company that runs the .tube gTLD, has claimed victory in its fight to get popular social media apps to “linkify” more than 400 TLDs that have gone live in the last eight years.

As I reported two weeks ago, CEO Rami Schwartz managed to figure out that any TLD that entered the root after November 2015 wasn’t being recognized by apps such as WhatsApp, the world’s most-popular messaging app.

This meant that any attempt to share a URL in .tube or 467 other TLDs (including major dot-brands and geo-gTLDs) would be frustrated by the fact that WhatsApp would not automatically turn the URL into a clickable link.

The root cause of the problem appeared to be a library used in the Android operating system, which had a hard-coded list of valid TLDs that had not been updated since November 2015.

In a press release today, the registry reported that the library in question was updated on September 11 (hey, that’s the same day I published my article!) with a brand-new list of TLDs.

So it seems the linkification issue will be solved, once the updated software actually makes it to affected devices.

There are not many TLDs in the pipeline for delegation for the next four years — maybe some contested 2012-round stragglers and the odd IDN ccTLD — so this particular issue is unlikely to cause much more upset for a while.

“This story exemplifies how the perseverance of a small company unearthed a Universal Acceptance issue of global significance, rallying the support of industry leaders and setting a precedent for cooperation that can positively impact billions of internet users,” the registry said in its press release.

Second DNSSEC screw-up takes down Aussie web sites

.au domains failed to resolve for many internet users for almost an hour on Monday, after the registry operator messed up a DNSSEC update.

ccTLD overseer auDA said the issue was caused by a “key re-signing process that generated an incorrect record”. Users on ISPs that strictly enforce DNSSEC would have returned not-found errors for .au domains during the outage.

.au’s technical back-end is managed by Identity Digital, which reportedly said that the outage lasted from 0005 UTC until 0052 UTC.

With over four million domains, .au is I believe the largest TLD zone to fall victim to DNSSEC-related downtime, but it’s not the first time it has happened to the domain.

In March 2022, thousands of .au domains were affected by a DNSSEC snafu that lasted a few hours.

DNSSEC is meant to make the DNS more secure by reducing the risk of man-in-the-middle attacks, but it’s appears to be easy to screw up, judging by a list of TLD outages. Just this year, Mexico, New Zealand and Venezuela have also suffered downtime.

Is this why WhatsApp hates some TLDs but not others?

Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains.

That’s the picture that seems to be emerging from one new gTLD operator’s quest to discover why WhatsApp doesn’t recognize its TLD, and many others including major dot-brands, as valid.

And ICANN isn’t interested in helping, despite its declared focus on Universal Acceptance, the CEO of this registry claims.

When most social media apps detect the user has inputted a URL or domain name, they automatically “linkify” it so it can be easily clicked or tapped without the need for copy/paste.

But when Rami Schwartz of new gTLD .tube discovered that .tube URLs sent via WhatsApp, said to have two billion users, were not being linkified, despite the TLD being delegated by ICANN almost eight years ago, he set out to find out why.

Schwartz compiled a spreadsheet (.xlsx) listing which gTLDs are recognized by WhatsApp and which are not and discovered a rough cut-off point in November 2015. TLDs delegated before then are linkified, those delegated after were not.

According to my database, 468 TLDs have been delegated since December 2015, though not all are still in the root. That’s about a third of all TLDs.

This means that, for example, .microsoft domains linkify but .amazon and .apple domains do not; .asia domains linkify but .africa and .arab domains do not; .london works but .abudhabi doesn’t. Even .verisign missed the cut-off.

If WhatsApp users include a “www.” or “http://” then the app will linkify the domain, even if the specified TLD does not exist.

During the course of a discussion on the web site of the Public Suffix List — which maintains an open-source list of all TLDs and the levels at which names may be registered — it was discovered that the problem may be deeper rooted than the WhatsApp app.

It turns out a library in the Android operating system contains a hard-coded list of valid TLDs which hasn’t been updated since November 24, 2015.

Any app relying on Android to validate TLDs may therefore be susceptible to the same problem — any TLD younger than seven years won’t validate. Schwartz tells us he’s experienced the same issues with the Facebook app on Android devices.

The problem is of particular concern to Schwartz because he’s been planning to market .tube as a form of link-shortening service, and without full support among the most popular messaging apps such a service would be much less attractive.

“I can’t launch this now if it’s not going to work in WhatsApp, if it’s not going to work in Facebook,” he said.

While engineers from Facebook/WhatsApp parent Meta now seem to be looking into the problem, Schwartz says his complaints fell on deaf ears for a long time.

He additionally claims that “ICANN doesn’t really care about universal acceptance” and his attempts to get the Org to pay attention to the problem have been brushed off, despite ICANN making Universal Acceptance one of its key priorities.

Schwartz says ICANN is much more interested in UA when it comes to internationalized domain names (those in non-Latin scripts, such as Arabic or Chinese) and not the technical issues that underpin the functionality of all TLDs.

“I’ve no idea why ICANN makes the decisions it makes, but I think it has to do with inclusion, I think it has to do with diversity, I think it has to do with a lot of things — not technical,” he said. “But this is a technical issue.”

ICANN maintains a set of UA technical resources on its web site and supports the work of the independent Universal Acceptance Steering Group.