Latest news of the domain name industry

Recent Posts

The internet is still working after KSK roll

Kevin Murphy, October 16, 2018, Domain Tech

The first-ever change to the security keys at the top of the DNS tree appears to have been a non-event.

While ICANN received reports of some disruptions after last Thursday’s KSK rollover, the impact appears to have fallen short of the millions of users that had been speculated.

ICANN said yesterday:

After evaluation of the available data, there does not appear to be a significant number of Internet end-users who have been persistently and negatively impacted by the changing of the key.

The few issues that have arisen appear to have been quickly mitigated and none suggested a systemic failure that would approach the threshold (as defined by the ICANN community) to initiate a reversal of the roll. In that context, it appears the rollover to the new Key Signing Key, known as KSK 2017, has been a success.

The KSK, also sometimes called the “trust anchor”, is the ultimate cryptographic key in the chain that secures all DNSSEC queries on the internet.

October 11 was the first time it had been changed since the first version came online in 2010.

While changing the key was broadly considered sound security practice, the roll was delayed by a year after it was discovered that potentially millions of endpoints were using DNS resolvers not properly configured to use the 2017 key.

After much research, outreach and gnashing of teeth, it was decided that the risk posed by rolling the KSK now fell within acceptable parameters of collateral damage.

Experts from the likes of Google and Verisign, and one ICANN director, had urged caution and said perhaps the roll should be delayed further while more data was gathered.

But they were in the minority, ICANN went ahead anyway, and it seems their fears have not come to pass.

The KSK is now likely to be rolled regularly — it could be as little as once every five years, or more frequently.

It also gives ICANN the opportunity to eventually update the system to swap out its current RSA keys for keys based on elliptical curve cryptography, which could reduce the traffic load on the DNS as a whole.

Google adds censorship workaround to Android devices

Kevin Murphy, October 5, 2018, Domain Tech

Google is using experimental DNS to help people in censorious regimes access blocked web sites.

Alphabet sister company Jigsaw this week released an Android app called Intra, which enables users to tunnel their DNS queries over HTTPS to compatible servers, avoiding common types of on-the-wire manipulation.

The company reportedly says it has been testing the app with Venezuelan dissidents recently.

The feature will also be built in to the next version of Android — known as Android 9 or Android Pie — where it will be called Private DNS.

The app is designed for people who for one reason or another are unable to update their device’s OS.

Intra and Private DNS use “DNS over HTTPS”, an emerging protocol Google and others have been working on for a while.

As it’s non-standard, end users will have to configure their devices or Intra apps to use a DoH-compatible DNS server. The public DNS services operated by Google (8.8.8.8) and Cloudflare (1.1.1.1) are both currently compatible.

The release comes even as Google faces controversy for allegedly kowtowing to the Chinese government’s demands for censored search and news results.

You may notice that the new app is being marketed via a .org web site, rather than Google’s own .app gTLD, but intra.app takes visitors directly to the Intra page on the Google Play store.

Emoji domains now easier to use

Kevin Murphy, September 25, 2018, Domain Tech

Emoji domains have become marginally easier to navigate to in the last month, following an update to Google’s Chrome browser.

Google has added “Emoji” to the context menu that appears when users right-click in any editable text field — including the address/search bar.

Clicking the option brings up a searchable list of common emojis that can be inserted into the address bar for either search or, with the addition of a typed-in TLD, navigation.

TLDs currently supporting emojis include .ws, .fm and .to. ICANN has ruled out support for emojis in the gTLDs for security reasons.

When the domain is resolved, the emojis render in the address bar as Punycode-converted Latin characters beginning with the usual “xn--” prefix, at least under my default configuration.

The whole process is still a bit fiddly, so I wouldn’t all rush out to build your businesses on emoji domains just yet.

The context menu feature appears to have been on the experimental track in Chrome for at least a month, but was more recently turned on by default, at least on all the Chrome 69 installs I’ve tested.

If you don’t get the emoji option in your context menu, you should be able to turn it on by navigating to chrome://flags/#enable-emoji-context-menu and selecting the Enabled option.

Whois privacy did NOT increase spam volumes

Kevin Murphy, August 31, 2018, Domain Tech

The advent of more-or-less blanket Whois privacy has not immediately led to the feared uptick in spam, according to researchers.

Data from Cisco’s Talos email data service, first highlighted by security company Recorded Future this week, shows spam levels have been basically flat to slightly down since ICANN’s GDPR-inspired new Whois policy came into effect May 25.

Public Talos data shows that on May 1 this year there were 433.9 billion average daily emails and 370.04 billion spams — 85.28% spam.

This was down to 361.83 billion emails and 308.05 billion spams by August 1, an 85.14% spam ratio, according to Recorded Future.

So, basically no change, and certainly not the kind of rocketing skyward of spam levels that some had feared.

Cisco compiles its data from customers of its various security products and services.

Looking at Talos’ 18-month view, it appears that spam volume has been on the decline since February, when the ratio of spam to ham was pretty much identical to post-GDPR levels.

It also shows a similar seasonal decline during the northern hemisphere’s summer 2017.

Talos graph

There had been a fear in some quarters that blanket Whois privacy would embolden spammers to register more domains and launch more ambitious spam campaigns, and that the lack of public data would thwart efforts to root out the spammers themselves.

While that may well transpire in future, the data seems to show that GDPR has not yet had a measurable impact on spam volume at all.

ICANN faces critical choice as security experts warn against key rollover

Kevin Murphy, August 23, 2018, Domain Tech

Members of ICANN’s top security body have advised the organization to further delay plans to change the domain name system’s top cryptographic key.

Five dissenting members of the influential, 22-member Security and Stability Advisory Committee said they believe “the risks of rolling in accordance with the current schedule are larger than the risks of postponing”.

Their comments relate to the so-called KSK rollover, which would see ICANN for the first time ever change the key-signing key that acts as the trust anchor for all DNSSEC queries on the internet.

ICANN is fairly certain rolling the key will cause DNS resolution problems for some — possibly as much as 0.05% of the internet or a couple million people — but it currently lacks the data to be absolutely certain of the scale of the impact.

What it does know — explained fairly succinctly in this newly published guide (pdf) — is that within 48 hours of the roll, a certain small percentage of internet users will start to see DNS resolution fail.

But there’s a prevailing school of thought that believes the longer the rollover is postponed, the bigger that number of affected users will become.

The rollover is currently penciled in for October 11, but the ultimate decision on whether to go ahead rests with the ICANN board of directors.

David Conrad, the organization’s CTO, told us last week that his office has already decided to recommend that the roll should proceed as planned. At the time, he noted that SSAC was a few days late in delivering its own verdict.

Now, after some apparently divisive discussions, that verdict is in (pdf).

SSAC’s majority consensus is that it “has not identified any reason within the SSAC’s scope why the rollover should not proceed as currently planned.”

That’s in line with what Conrad, and the Root Server System Advisory Committee have said. But SSAC noted:

The assessment of risk in this particular area has some uncertainty and therefore includes a component of subjective judgement. Individuals (including some members of the SSAC) have different assessments of the overall balance of risk of the resumption of this plan.

It added that it’s up to the ICANN board (comprised largely of non-security people) to make the final call on what the acceptable level of risk is.

The minority, dissenting opinion gets into slightly more detail:

The decision to proceed with the keyroll is a complex tradeoff of technical and non-technical risks. While there is risk in proceeding with the currently planned roll, we understand that there is also risk in further delay, including loss of confidence in DNSSEC operational planning, potential for more at-risk users as more DNSSEC validation is deployed, etc.

While evaluating these risks, the consensus within the SSAC is that proceeding is preferable to delay. We personally evaluate the tradeoffs differently, and we believe that the risks of rolling in accordance with the current schedule are larger than the risks of postponing and focusing heavily on additional research and outreach, and in particular leveraging newly developed techniques that provide better signal and fidelity into potentially impacted parties.

We would like to reiterate that we understand our colleagues’ position, but evaluate the risks and associated mitigation prospects differently. We believe that the ultimate decision lies with the ICANN Board, and do not envy them with this decision.

SSAC members are no slouches when it comes to security expertise, and the dissenting members are no exception. They are:

  • Lyman Chapin, co-owner of Interisle Consulting, a regular ICANN contractor perhaps best-known to DI readers for carrying out a study into new gTLD name collisions five years ago.
  • Kimberly “kc claffy” Claffy, head of the Center for Applied Internet Data Analysis at the University of California in San Diego. CAIDA does nothing but map and measure the internet.
  • Jay Daley, a registry executive with a technical background whose career includes senior stints at .uk and .nz. He’s currently keeping the CEO’s chair warm at .org manager Public Interest Registry.
  • Warren Kumari, a senior network security engineer at Google, which is probably the largest early adopter of DNSSEC on the resolution side.
  • Danny McPherson, Verisign’s chief security officer. As well as .com, Verisign runs the two of the 13 root servers, including the master A-root. It’s running the boxes that sit at the top of the DNSSEC hierarchy.

It may be the first time SSAC has failed to reach a full-consensus opinion on a security matter. If it has ever published a dissenting opinion before, I certainly cannot recall it.

The big decision about whether to proceed or delay is expected to be made by the ICANN board during its retreat in Brussels, a three-day meeting that starts September 14.

Given that ICANN’s primary mission is “to ensure the stable and secure operation of the Internet’s unique identifier systems”, it could turn out to be one of ICANN’s biggest decisions to date.