Latest news of the domain name industry

Recent Posts

Telco billed $2.7 million for failing to renew domain

Kevin Murphy, October 2, 2017, Domain Tech

A US telecommunications provider has agreed to pay $2.7 million after an emergency service went offline because it forgot to renew a domain name.

According to the Federal Communications Commission, Utah-based Sorenson Communications saw its “video relay service” go offline for two days in June 2016 after a domain was not renewed.

The service is basically a 911 emergency calls replaced designed for people with hearing or speech problems.

The settlement (pdf) describes the scenario like this:

Sorenson.com is a domain name Sorenson uses to provide access to SVRS. On the morning of June 6, 2016, Sorenson experienced a VRS Service Interruption that resulted from a preventable, internal operational failure.10 This failure led the domain registration for Sorenson.com to expire and be deactivated. After the deactivation occurred and before Sorenson could correct the situation, some Internet Service Providers (ISPs) updated their records to reflect that the domain was expired. If a user’s ISP updated its records while the domain was shown as expired, that user could not make or receive calls routed through Sorenson.com — including VRS, 911, Dial-Around, and Point-to-Point calls — during at least part of the outage.

Upon discovery of the VRS Service Interruption, Sorenson took immediate steps to correct the problem and notify callers. Once the domain name was reactivated, each caller’s ISP had to take certain steps to ensure that calls were routed through Sorenson.com. To expedite this process, Sorenson reached out to multiple large ISPs, such as Verizon and Comcast, and posted information about the VRS Service Interruption on its website11 and social media outlets. The VRS Service Interruption continued for some callers through the morning of June 8, 2016.

The $2.7 million charge is a repayment of a reimbursement of the same amount paid out by the nation Telecommunications Relay Service Fund.

Sorenson has agreed to pay a more modest $252,000 in formal penalties to the FCC for its indiscretion.

Still, as domain renewal fumbles go, it’s got to be one of the biggest facepalms we’ve seen for a while.

New gTLDs still a crappy choice for email — study

Kevin Murphy, September 28, 2017, Domain Tech

New gTLDs may not be the best choice of domain for a primary email address, judging by new research.

Over 20% of the most-popular web sites do not fully understand email addresses containing long TLDs, and Arabic email addresses are supported by fewer than one in 10 sites, a study by the Universal Acceptance Steering Group has found.

Twitter, IBM and the Financial Times are among those sites highlighted as having only partial support for today’s wide variety of possible email addresses.

Only 7% of the sites tested were able to support all types of email address.

The study, carried out by Donuts and ICANN staff, looked at 749 websites (in the top 1,000 or so as ranked by Alexa) that have forms for filling in email addresses.

On each site, seven different email addresses were input, to see whether the site would accept them as valid.

The emails used different combinations of ASCII and Unicode before the dot and mixes of internationalized domain name and ASCII at the second and top levels.

These were the results (click to enlarge or download the PDF of the report here):

IDN emails

The problem with these numbers, it seems to me, is the lack of a control. There’s no real baseline to judge the numbers against.

There’s no mention in the paper about testing addresses that use .com or decades-old ccTLDs, which would have highlighted web sites that with broken scripts that reject all emails.

But if we assume, as the paper appears to, that all the tested web sites were 100% compliant for .com domains, the scores for new gTLDs are not great.

There are currently over 800 TLDs over four characters in length, but according to the UASG research 22% of web sites will not recognize them.

There are 150 IDN TLDs, but a maximum of 30% of sites will accept them in email addresses.

When it comes to right-to-left scripts, such as Arabic, the vast majority of sites are totally hopeless.

UASG dug into the code of the tested sites when it could and found that most of them use client-side code — JavaScript processing a regular expression — to verify addresses.

A regular expression is complex bit of code that can look something like this: /^.+@(?:[^.]+\.)+(?:[^.]{2,})$

It’s not every coder’s cup of tea, but it can get the job done with minimal client-side resource overheads. Most coders, the UASG concludes, copy regex they found on a forum and maybe tweak it a bit.

This should not be shocking news to anyone. I’ve known about it since 2009 or earlier when I first started ripping code from StackOverflow.

However, the UASG seems to be have been working on the assumption that more sites are using off-the-shelf software libraries, which would have allowed the problem to be fixed in a more centralized fashion.

It concludes in its paper that much greater “awareness raising” needs to happen before universal acceptance comes closer to reality.

ICANN just came thiiis close to breaking the internet

Kevin Murphy, September 28, 2017, Domain Tech

ICANN has decided to postpone an unprecedented change at the DNS root after discovering it could break internet for potentially millions of users.

The so-called KSK Rollover was due to go ahead on October 11, but it’s now been pushed back to — tentatively — some time in the first quarter 2018.

The delay was decided after ICANN realized that there were still plenty of ISPs and network operators that weren’t ready for the change.

Had ICANN gone ahead anyway with the change anyway, it could have seen subscribers of affected ISPs lose access to millions of DNSSEC-supporting domain names.

So the postponement is a good thing.

A KSK or Key Signing Key is a public-private cryptographic key pair used to sign other keys called Zone Signing Keys. The root KSK signs the root ZSK and is in effect the apex of the DNSSEC hierarchy.

The same KSK has been in operation at the root since 2010, when the root was first signed, but it’s considered good practice to change it every so often to mitigate the risk of brute-force attacks against the public key.

While it’s important enough to get dramatized in US spy shows, in practice it only affects ISPs and domain names that voluntarily support DNSSEC.

ICANN estimates that 750 million people use DNSSEC, which is designed to prevent problems such as man-in-the-middle attacks against domain names.

That’s a hell of a lot of people, but it’s still a minority of the world’s internet-using population. It’s not been revealed how many of those would have been affected by a premature rollover.

When DNSSEC fails, people whose DNS resolvers have DNSSEC turned on (Comcast and Google are two of the largest such providers) can’t access domain names that have DNSSEC turned on (such as domainincite.com).

Preventing the internet breaking is pretty much ICANN’s only job, so it first flagged up its intention to roll the root KSK back in July last year.

In July this year, the new public KSK was uploaded as part of a transition phase that is seeing the 2010 keys and 2017 keys online simultaneously.

Last year, CTO David Conrad told us the long lead time and cautious approach was necessary to get the word out that ISPs needed to test their resolvers to make sure they would work with the new keys.

In June, ICANN CEO Goran Marby spammed the telecommunications regulators in every country in the world with a letter (pdf) asking them to coordinate their home ISPs to be ready for the change.

The organization’s comms teams has also been doing a pretty good job getting word of the rollover into the tech press over the last few months.

But, with a flashback to the new gTLD program, that outreach doesn’t seem to have reached out as far as it needed to.

ICANN said last night that a “significant number” of ISPs are still not ready for the rollover.

It seems ICANN only became aware of this problem due to a new feature of DNS that reports back to the root which keys it is configured to use.

Without being able to collate that data, it’s possible it could have been assumed that the situation was hunky-dory and the rollover might have gone ahead.

ICANN still isn’t sure why so many resolvers are not yet ready for the 2017 KSK. It said in a statement:

There may be multiple reasons why operators do not have the new key installed in their systems: some may not have their resolver software properly configured and a recently discovered issue in one widely used resolver program appears to not be automatically updating the key as it should, for reasons that are still being explored.

It’s not clear why the broken resolver software has not been named — one would assume that getting the word out would be a priority unless issues of responsible disclosure were in play.

ICANN said it is “reaching out to its community, including its Security and Stability Advisory Committee, the Regional Internet Registries, Network Operator Groups and others to help explore and resolve the issues.”

The organization is hopeful that it will be able to go ahead with the rollover in Q1 2018, but noted that would be dependent on “more fully understanding the new information and mitigating as many potential failures as possible.”

While it’s excellent news that ICANN is on top of the situation, the delay is unlikely to do anything to help the perception that DNSSEC is mainly just an administrative ball-ache and far more trouble than it’s worth.

Pilot program for Whois killer launches

Kevin Murphy, September 7, 2017, Domain Tech

ICANN is to oversee a set of pilot programs for RDAP, the protocol expected to eventually replace Whois.

Registration Data Access Protocol, an IETF standard since 2015, fills the same function as Whois, but it is more structured and enables access control rules.

ICANN said this week that it has launched the pilot in response to a request last month from the Registries Stakeholder Group and Registrars Stakeholder Group. It said on its web site:

The goal of this pilot program is to develop a baseline profile (or profiles) to guide implementation, establish an implementation target date, and develop a plan for the implementation of a production RDAP service.

Participation will be voluntary by registries and registrars. It appears that ICANN is merely coordinating the program, which will see registrars and registrars offer their own individual pilots.

So far, no registries or registrars have notified ICANN of their own pilots, but the program is just a few days old.

It is expected that the pilots will allow registrars and registries to experiment with different types of profiles (how the data is presented) and extensions before ICANN settles on a standard, contractually enforced format.

Under RDAP, ICANN/IANA acts as a “bootstrapping” service, maintaining a list of RDAP servers and making it easier to discover which entity is authoritative for which domain name.

RDAP is basically Whois, but it’s based on HTTP/S and JSON, making it easier to for software to parse and easier to compare records between TLDs and registrars.

It also allows non-Latin scripts to be more easily used, allowing internationalized registration data.

Perhaps most controversially, it is also expected to allow differentiated access control.

This means in future, depending on what policies the ICANN community puts in place, millions of current Whois users could find themselves with access to fewer data elements than they do today.

The ICANN pilot will run until July 31, 2018.

About that $3,800 emoji domain sale…

Kevin Murphy, June 5, 2017, Domain Tech

The debate over the age of the emoji domain name ☮.com may have been settled. It probably is as old as it was claimed to be.

You may recall that last week I blogged about the €3,400 ($3,816) sale of the domain to an end user. It wasn’t a big sale or a big story, but it’s so rare to see an emoji name sell I thought it was worth a few paragraphs.

It had been claimed, and I reported, that the name was 16 years old, having been registered in April 2001.

Later that day, ICANN principle technologist Paul Hoffman, who was co-author of the IDNA2003 standard that governed how non-ASCII domains were represented in the DNS, questioned whether the name could possibly be that old.

Under IDNA2003, IDNs are encoded with the “xn--” prefix. While applications may render ☮.com as the “peace” symbol, in the DNS it is in fact xn--v4h.com.

Hoffman told me that the prefix had been picked more or less at random in March 2003, so there was no way a speculator could have known in April 2001 how to register a domain that would have no meaning for another two years.

In addition, the Punycode standard that converts non-Latin characters to ASCII was not finalized until 2003 either.

It seemed more likely that the creation date in the Whois record was incorrect, so I updated the original blog post with the new information.

That kicked off a bit of a debate in the comments about scenarios in which the creation date was correct. Some commenters wondered whether the original buyer had registered many domains with different prefixes with the hope of getting lucky.

What none of us considered was that the domain itself changed between 2001 and 2003. Given new information Hoffman supplied over the weekend, that now strikes me as the most plausible scenario.

What most of us had forgotten was that Verisign launched an IDN registration test-bed all the way back in December 2000 (archive.org link).

That roll-out, controversial at the time, encoded the domains with Punycode predecessor RACE and used the bq– prefix.

However, after the IDNA2003 and Punycode standards were published in 2003, Verisign then converted all of the existing IDN .com domains over to the two new standards. Names beginning bq– were changed to xn--, and the encoding of the subsequent characters was changed.

So ☮.com very probably was registered in 2001, but in ASCII it was a completely different domain name back then.

We seem to have a rare(ish) case here of the creation date in the Whois being “right” but the domain name itself being “wrong”.

There may be as many as half a million .com domains with similar issues in their Whois.

I hope this clears up any confusion.