Latest news of the domain name industry

Recent Posts

Zone file access is crap, security panel confirms

Kevin Murphy, June 20, 2017, Domain Policy

ICANN’s Centralized Zone Data Service has some serious shortcomings and needs an overhaul, according to the Security and Stability Advisory Committee.

The panel of DNS security experts has confirmed what CZDS subscribers, including your humble correspondent, have known since 2014 — the system had a major design flaw baked in from day one for no readily apparent reason.

CZDS is the centralized repository of gTLD zone files. It’s hosted by ICANN and aggregates zones from all 2012-round, and some older, gTLDs on a daily basis.

Signing up for it is fairly simple. You simply fill out your contact information, agree to the terms of service, select which zones you want and hit “submit”.

The purpose of the service is to allow researchers to receive zone files without having to enter into separate agreements with each of the 1,200+ gTLDs currently online.

The major problem, as subscribers know and SSAC has confirmed, is that the default subscription period is 90 days.

Unless the gTLD registry extends the period at its end and in its own discretion, each subscription ends after three months — cutting off access — and the subscriber must reapply.

Many of the larger registries exercise this option, but many — particularly dot-brands — do not.

The constant need to reapply and re-approve creates a recurring arse-ache for subscribers and, registry staff have told me, the registries themselves.

The approval process itself is highly unpredictable. Some of the major registries process requests within 24 hours — I’ve found Afilias is the fastest — but I’ve been waiting for approval for Valuetainment’s .voting since September 2016.

Some dot-brands even attempt to insert extra terms of service into the deal before approving requests, which defeats the entire purpose of having a centralized service in the first place.

Usually, a polite email to the person handling the requests can produce results. Other times, it’s necessary to report them to ICANN Compliance.

The SSAC has evidently interviewed many people who share my concerns, as well as looking at data from Compliance (where CZDS reliably generates the most complaints, wasting the time of Compliance staff).

This situation makes zone file access unreliable and subject to unnecessary interruptions. The missing data introduces “blind spots” in security coverage and research projects, and the reliability of software – such as security and analytics applications – that relies upon zone files is reduced. Lastly, the introduced inefficiency creates additional work for both registry operators and subscribers.

The SSAC has no idea why the need to reapply every 90 days was introduced, figuring it must have happened during implementation.

But it recommends that access agreements should automatically renew once they expire, eliminating the busywork of reapplying and closing the holes in researchers’ data sets.

As I’m not objective on this issue, I agree with that recommendation wholeheartedly.

I’m less keen on the SSAC’s recommendation that registries should be able to opt out of the auto-renewals on a per-subscriber basis. This will certainly be abused by the precious snowflake dot-brands that have already shown their reluctance to abide by their contractual obligations.

The SSAC report can be read here (pdf).

Emoji domains get a 👎 from security panel

Kevin Murphy, May 30, 2017, Domain Tech

The use of emojis in domain names has been discouraged by ICANN’s Security and Stability Advisory Committee.

In a paper late last week, SSAC told ICANN that emojis — aka emoticons or smileys — lack standardization, are barred by the relevant domain name technical standards, and could cause user confusion.

Emoji domains, while technically possible, are not particularly prevalent on the internet right now.

They’re implicitly banned in gTLDs due to the contractual requirement to adhere to the IDNA2008 standard, which restricts internationalized domain names to actual spoken human languages, and the only ccTLD I’m aware of actively marketing the names is Samoa’s .ws.

There was a notable example of Coca Cola registering 😀.ws (xn--h28h.ws) for a billboard marketing campaign in Puerto Rico a couple of years ago, but that name has since expired and been registered by an Australian photographer.

The SSAC said that emoji use should be banned in TLDs and discouraged at the second level for several reasons.

Mainly, the problem is that while emojis are described in the Unicode standards, there’s no standardization across devices and applications as to how they are displayed.

A certain degree of creative flair is permitted, meaning a smiling face in one app may look unlike the technically same emoji in another app. On smaller screens and with smaller fonts, technically different emojis may look alike.

This could lead to confusion, which could lead to security problems, SSAC warns:

It is generally difficult for people to figure out how to specify exactly what happy face they are trying to produce, and different systems represent the same emoji with different code points. The shape and color of emoji can change while a user is viewing them, and the user has no way of knowing whether what they are seeing is what the sender intended. As a result, the user is less likely to reach the intended resource and may instead be tricked by a phishing site or other intentional misrepresentation.

SSAC added that it:

strongly discourages the registration of any domain name that includes emoji in any of its labels. The SSAC also advises registrants of domain names with emoji that such domains may not function consistently or may not be universally accessible as expected

The brief paper can be read here (pdf).

Security experts say ICANN should address collisions before approving more new TLDs

Kevin Murphy, January 2, 2017, Domain Tech

ICANN’s Security and Stability Advisory Committee has told ICANN it needs to do more to address the problem of name collisions before it approves any more new gTLDs.

In its latest advisory (pdf), published just before Christmas, SSAC says ICANN is not doing enough to coordinate with other technical bodies that are asserting authority over “special use” TlDs.

The SAC090 paper appears to be an attempt to get ICANN to further formalize its relationship with the Internet Engineering Task Force as it pertains to reserved TLDs:

The SSAC recommends that the ICANN Board of Directors take appropriate steps to establish definitive and unambiguous criteria for determining whether or not a syntactically valid domain name label could be a top-level domain name in the global DNS.

Pursuant to its finding that lack of adequate coordination among the activities of different groups contributes to domain namespace instability, the SSAC recommends that the ICANN Board of Directors establish effective means of collaboration on these issues with relevant groups outside of ICANN, including the IETF.

The paper speaks to at least two ongoing debates.

First, should ICANN approve .home and .corp?

These two would-be gTLDs were applied for by multiple parties in 2012 but have been on hold since August 2013 following an independent report into name collisions.

Names collisions are generally cases in which ICANN delegates a TLD to the public DNS that is already broadly used on private networks. This clash can result in the leakage of private data.

.home and .corp are by a considerable margin the two strings most likely to be affected by this problem, with .mail also seeing substantial volume.

But in recent months .home and .corp applicants have started to put pressure on ICANN to resolve the issue and release their applications from limbo.

The second incident the SSAC paper speaks to is the reservation in 2015 of .onion

If you’re using a browser on the privacy-enhancing Tor network, .onion domains appear to you to work exactly the same as domains in any other gTLDs, but under the hood they don’t use the public ICANN-overseen DNS.

The IETF gave .onion status as a “Special Use Domain“, in order to prevent future collisions, which caused ICANN to give it the same restricted status as .example, .localhost and .test.

But there was quite a lot of hand-wringing within the IETF before this status was granted, with some worrying that the organization was stepping on ICANN’s authority.

The SSAC paper appears to be designed at least partially to encourage ICANN to figure out how much it should take its lead from the IETF in this respect. It asks:

The IETF is an example of a group outside of ICANN that maintains a list of “special use” names. What should ICANN’s response be to groups outside of ICANN that assert standing for their list of special names?

For members of the new gTLD industry, the SSAC paper may be of particular importance because it raises the possibility of delays to subsequent rounds of the program if ICANN does not spell out more formally how it handles special use TLDs.

“The SSAC recommends that ICANN complete this work before making any decision to add new TLD names to the global DNS,” it says.

Is the .home new gTLD doomed? ICANN poses study of security risks

Kevin Murphy, May 22, 2013, Domain Tech

ICANN has set up a study into whether certain applied-for new gTLD strings pose a security risk to the internet, admitting that some gTLDs may be rejected as a result.

Its board of directors on Saturday approved new research into the risk of new gTLD clashes with “internal name certificates”, saying that the results could kill off some gTLD applications.

In its rationale, the board stated:

it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

Internal name certificates are the same digital certificates used in secure, web-based SSL transactions, but assigned to domain names in private, non-standard namespaces.

Many companies have long used non-existent TLDs such as .corp, .mail and .home on their private networks and quite often they obtain SSL certs from the usual certificate authorities in order to enable encryption between corporate resources and their internal users.

The problem is that browsers and other applications on laptops and other mobile devices can attempt to access these private namespaces from anywhere, not only from the local network.

If ICANN should set these TLD strings live in the authoritative DNS root, registrants of clashing domain names might be able to hijack traffic intended for secure resources and, for example, steal passwords.

That’s obviously a worry, but it’s one that did not occur to ICANN’s Security and Stability Advisory Committee until late last year, when it immediately sought out the help of the CA/Browser Forum.

It turned out the the CA/Browser forum, an alliance of certificate authorities and browser makers, was already on the case. It has put in new rules that state certificates issued to private TLDs that match new gTLDs will be revoked 120 days after ICANN signs a contract with the new gTLD registry.

But it’s still not entirely clear whether this will sufficiently mitigate risk. Not every CA is a member of the Forum, and some enterprises might find 120 day revocation windows challenging to work with.

Verisign recently highlight the internal certificate problem, along with many other potential risks, in an open letter to ICANN.

But both ICANN CEO Fadi Chehade and the chair of SSAC, Patrick Falstrom, have said that the potential security problems are already being addressed and not a reason to delay new gTLDs.

The latest board resolution appears to modify that position.

The board has now asked CEO Fadi Chehade and SSAC to “consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.”

The Root Server Stability Advisory Committee and the CA/Browser Forum will also be tapped for data.

While the study will, one assumes, not be limited to any specific applied-for gTLD strings, it’s well known that some strings are more risky than others.

The root server operators already receive vast amounts of erroneous DNS traffic looking for .home and .corp, for example. If any gTLD applications are at risk, it’s those.

There are 10 remaining applications for .home and five for .corp.

Afilias exec returns to ICANN board

Kevin Murphy, August 11, 2012, Domain Policy

Afilias chief technology officer Ram Mohan has been reappointed to ICANN’s board of directors for a fourth year.

He’s the Security and Stability Advisory Committee’s non-voting liaison, joining the board in 2009.

According to a notice (pdf) posted on ICANN’s web site yesterday, he’s been picked to continue in the role for another year.

Board liaisons, who are unpaid, serve annual terms and there are no limits on the number of years they can serve.

As arguably the most-conflicted person on the ICANN board in relation to new gTLDs, Mohan does not sit in on discussions of the program.

  • Page 1 of 2
  • 1
  • 2
  • >