It’s official: Verisign has balls of steel

Verisign has spent the last six months telling anyone who will listen that new gTLDs will kill Japanese people and cause electricity grids to fail, so you’d expect the company to be a little coy about its own activities that (applying Verisign logic) endanger life and the global economy.
But apparently not.
Verisign today decided to use the same blog it has been using to play up the risks indicated by NXDOMAIN traffic in new gTLDs to plug its own service that actively encourages people to register error-traffic domains.
The company has launched DomainScope, which combines several older “domain discovery” tools — DomainFinder, DomainScore and DomainCountdown — under one roof.
According to an unsigned corporate blog post, with my emphasis:

DomainScope enables users to discover domain name registration opportunities through learning about the recent history of a domain name, understanding a domain name’s DNS traffic patterns, and knowing which domains are available that are receiving traffic.

That’s right, Verisign is giving malicious hackers the ability, for free, to find out which .com, .net and .tv domains currently receive NXDOMAIN traffic, so that the hackers can pay Verisign to register them and cause mayhem.
I used the service today see what mischief might be possible, and hit paydirt on my first query.
Typing in “mail” as the search query, ordering the results by “Traffic Score” — a 1 to 10 measure of how much error traffic a domain already gets — I got these results:

You’ll notice (click to enlarge if you don’t) that the third result, with a 9.9 out of 10 score, is netsoolmail.net.
That caught my attention for obvious reasons, and a little Googling seems to confirm that it’s a typo of netsolmail.net, a domain Network Solutions uses for its mail servers (or possibly a spam filter).
Network Solutions is of course a top-ten registrar with millions of mostly high-end customers.
So what?
Well, if Verisign’s arguments are to be believed, this poses a huge risk of information leakage — something that should be avoided at all costs in new gTLDs but which is apparently just fine in .com and .net.
Emails set to go to netsoolmail.net will fail today due to an NXDOMAIN response. But what happens when somebody registers that domain (which is likely to happen about 10 minutes after this post is published)?
Do they suddenly start receiving thousands of sensitive emails intended for NetSol’s customers?
Could NetSol’s spam filters all start to fail, causing SOMEBODY TO DIE! from a dodgy Viagra?
I don’t know. No clue. Probably not.
But there’s a risk, right? Even if it’s a very small risk (as Verisign argues), shouldn’t ICANN be preventing Verisign from promoting these domains, maybe using some kind of massive block-list?
Data leakage is important enough to Versign that it was the headline risk it posed in a recent report aimed at getting new gTLDs delayed.
In an August “technical report” entitled “New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis”, somebody from Verisign wrote (pdf):

once delegated, the registrants under new gTLDs have the ability to register specific domains for targeted collisions
…
This form of information leakage can violate privacy of users, provide a competitive advantage between business rivals, expose details of corporate network infrastructures, or even be used to infer details about geographical locations of network assets or users

What the report fails to mention is that registrants today have this ability, and that Verisign is actively encouraging the practice.
In Yiddish they call what Verisign has done today chutzpah.
In British English, we call it taking the piss.

dotShabaka Diary — Day 20, Positive signs?

The twentieth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Friday 18 October 2013
Maybe we are starting to see some positive steps from ICANN towards delegation:
We received a revised Registry Agreement, Specification six that includes the requirements for Name Collision Occurrence Management and Report Handling.
ICANN made an announcement that included the statement that collision “…assessments and SLD lists will be posted to the specific TLD’s registry agreement page on the ICANN website. The first of these will be available before the end of this week.”
ICANN reached out this week and requested a detailed list of contacts for legal, media, financial, emergency, CZDS, TMDB, abuse, URS and compliance.
We are still waiting for ICANN to comment on the TMCH launch issues highlighted in our 12 October 12 journal.
Oh, and we are still waiting for the Welcome Pack!

Read previous and future diary entries here.

.shopping ruled confusingly similar to .shop

An International Centre for Dispute Resolution panelist has ruled that .shop and .shopping are too confusingly similar to coexist on the internet.
The panelist was Robert Nau, the same guy who ruled that .通販 and .shop are confusingly similar.
Again, the objector is .shop applicant Commercial Connect, which filed String Confusion Objections against almost every new gTLD application related to buying stuff online.
The defendant in this case was Donuts, via subsidiary Sea Tigers LLC.
Here’s the key part of the decision:

the concurrent use of “shopping”, the participle, and the root word “shop”, in gTLD strings will result in probable confusion by the average, reasonable Internet user, because the two strings have sufficient similarity in sound, meaning, look and feel. The average Internet user would not be able to differentiate between the two strings, and in the absence of some other external information (such as an index or guidebook) would have to guess which of the two strings contains the information the user is looking to view.
The adopters of the applicable standard of review for string confusion hypothetically could have allowed an unlimited number of top level domain names using the same root, and simply differentiate them by numbers, e.g., <.shop1>, <.shop2>, <.shop3>, etc., or other modifiers, including pluralization, or other similar variations of a root word, or other modifiers before or after the root word. While that might allow for increased competition, as argued by Applicant, it would only lead to a greater level of confusion and uncertainty among average, reasonable Internet users. Accordingly, the Applicant’s argument that the concurrent use of a root word and its participle version in a string increases competition is not persuasive in this context, and is rejected.

So far, Commercial Connect has lost 15 of the 21 SCOs it filed, against strings as weird as .supply and .shopyourway. Four cases remain open.
There are nine applicants for .shop, including Commercial Connect. Uniregistry has also applied for .shopping, but did not receive an objection.

Name collision block-lists to be published this week

ICANN will begin to publish the lists of domains that new gTLD registries must block at launch as early as this week, according to an updated name collisions plan released last night.
Registries that have already signed contracts with ICANN will be given their block-lists “before the end of this week”, ICANN said.
Registries that were not able to sign contracts because they’d been given an “uncalculated risk” categorization will now be invited, in priority order, to contracting.
The base Registry Agreement itself has been updated — unilaterally — to include provisions requiring registries to block second-level names deemed risky when they are delegated.
For each contracted gTLD, ICANN will provide what it’s calling a SLD Collision Occurrence Assessment, which will outline the steps registries need to take to mitigate their own collision risk.
It is also expected to contain a list of SLDs that have been seen on the Day In The Life Of The Internet data sets, collected from root server operators over 48-hour periods between 2006 and 2013.
Using previous years’ DITL data is news to me, and could potentially greatly expand the number of SLDs — already expected to be in the thousands in many cases — that registries are obliged to block.
“Most” new gTLD applicants are expected to be eligible for what ICANN calls an “alternative path to delegation”, in which the registry simply blocks the SLDs on an ICANN-provided list, gets delegated, and deals with the SLD Collision Occurrence Assessment at a later date.
Here’s how ICANN described the timetable for this:

For Registry Operators with executed registry agreements the Assessments and SLD lists will be posted to the specific TLD’s registry agreement page on the ICANN website. The first of these will be available before the end of this week.
In the coming weeks ICANN will post the alternative path eligibility assessments and SLD lists for all applied-for gTLDs.

In other words, if you haven’t already signed a contract there’s not yet a firm date on when you’ll find out how many — and which — names you’re expected to block, or even if you’re eligible for the alternative delegation path.

dotShabaka Diary — Day 19

The eighteenth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Tuesday 15 October 2013
Still no advice from ICANN on transition to IANA. As we approach the transition to delegation and start launch processes, we remain concerned about the following process and schedule risks:
ICANN have made references to the TLD Startup information being submitted “…via the customer service portal or other mechanism” but have not provided details. We are concerned that the TLD Startup interface has not been provided. Why not allow TLDs to enter the information now and submit it to ICANN once delegated to the root zone?
The process to ‘Email ICANN CSC – Confirm Tests Completed’ is not documented. Without a process definition or certificate to confirm IBM’s email advice that شبكة. has “passed TMDB testing” we risk ICANN rejecting the launch submission and the Sunrise schedule being thrown out.
ICANN have stated the TLD Startup Information must include confirmation that the TMCH Sunrise and Claims Operator has accepted the start and end dates prior to the Registry Operator providing the TLD Startup Information. There is no process documented for submitting the start and end dates to the TMCH.
If we choose the ‘Alternate Path to Delegation’ as defined in the ‘New gTLD Collision Occurrence Management Plan’ we need to block all second-level labels that appear in DNS requests to the applied-for TLD in the DITL and other relevant dataset. ICANN have committed to developing the list of labels but have not defined a timeline or distribution process. Why not distribute the list now so we don’t have to manage Registry change after the transition process starts?

Read previous and future diary entries here.

Second dot-brand gets ICANN contract

CITIC Group has signed a new gTLD Registry Agreement with ICANN, the second dot-brand to do so.
The Chinese financial services giant signed on the dotted line for .中信, the Chinese-script version of its company name.
The company has also applied for .citic, but that application is a little further down ICANN’s processing queue.
A little over two weeks ago, Samsung became the first dot-brand to enter into an ICANN registry contract.
CITIC becomes the 58th new gTLD with a contract, though 613 have been invited to contracting.
UPDATE: Oops! Thanks to the reader who alerted me to the fact that .中信 is actually the third dot-brand with a contract. The gTLD .otsuka (which is a Japanese pharmaceuticals company and not, as I thought, a geographic region) was in fact the second. I regret the error.

ITU says numeric .tel domains “may be confusing”

The International Telecommunication Union has warned ICANN that numeric .tel domain names, due to be released by Telnic tomorrow, “may confuse customers or cause undue conflicts”.
In a letter to ICANN, Malcolm Johnson, director of the ITU’s Telecommunication Standardization Bureau, said that there’s a risk that numbers-only .tel name could be confused with the E.164 numbering plan.
Johnson asked ICANN to explain how these numbers will be allocated and used:

ITU must express its concern about TELNIC’s recent announcement launching an “all numeric .tel domains” service from 15 October 2013. This raises a number of policy, legal, and practical implications on the potential usage of all-digit strings, not only under .TEL domain, but also under any future telephony-related new gTLDs
…
We are seeking this clarification as the digit strings appear similar to telephone numbers and could be used in a manner similar to telephone numbers, which may confuse customers or cause undue conflicts arising from their use.

E.164 is the standard for phone numbers worldwide. The ITU has been angsty about the potential for clashes ever since .tel was first proposed back in 2000.
Indeed, Telnic promised when it applied in 2003 not to allow numbers in .tel, precisely in order to calm these fears.
But when it asked for this self-imposed ban to be lifted in 2010, the ITU didn’t have anything to say (at least, it did not respond to ICANN’s public comment period).
Read Johnson’s letter here (pdf).

dotShabaka Diary — Day 18, More TMCH uncertainty

The eighteenth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Friday 11 October 2013
We are not sure if anyone else has noticed, but there are differences between the published documentation for Rights Protection Mechanisms, Trademark Clearinghouse and the transition to delegation process. This has created confusion.
To seek clarification, we sent the following questions to ICANN for a response:
Issue 1
IBM confirmed in an email on the 4th of October that شبكة. has passed TMDB testing. The message was:
“…confirm that all tests are ok and have asked to forward your certification request to ICANN.”
Based on this correspondence, it is our understanding that we are at the “Email ICANN CSC – Confirm Tests Completed” stage of the process as outlined in IBM’s TMCH swim lane diagram (pdf).
The next action in the process is ICANN’s – “CSC Sends Request to Registry Services for Actual Sunrise and Claims Start/End Dates”. Our understanding is that the reference to Registry Services is the Registry Services department of ICANN. The CSC will not be able to complete the next action “CSC Updates Existing Line in .csv File with Actual S&C Start/End Dates” until the Registry Operator submits its notice to ICANN (after it is delegated).
Can you please confirm there is no formal step where ICANN (or IBM) provides the Registry Operator with a “pass” certificate or other formal confirmation.
Issue 2
Section 2.1.1 of the RPM Requirements Document (pdf) states that the Registry Operator must provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator. However, section 2.1.2 states that such information must be submitted through the customer service portal.
Can you confirm that submission of the TLD Startup Information through the portal serves to satisfy the requirement to provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator as specified in Section 2.1.1?
Issue 3
Section 2.1.1.1 states that the TLD Startup Information needs to include confirmation that the registry operator has completed testing.
Does this confirmation need to be in a specific form?
Will an email from IBM suffice? If so, who must the email be from i.e. project manager and what must it state specifically?
Issue 4
Section 2.1.1.2 states that the TLD Startup Information needs to include confirmation that the TMCH Sunrise and Claims Operator has accepted the start and end dates prior to the Registry Operator providing the TLD Startup Information. This step of the process is not described in the Process Document.
Does this confirmation need to be in a specific form?
Does IBM have a SLA with ICANN to ensure such confirmation is provided within a specific timeframe to ensure that a Registry Operator’s ability to submit its TLD Startup Information is not compromised by delays?
Issue 5
For clarity can you incorporate the requirements of section 2.1 of the RPM Requirements Document into the TMDB Registration and Access to Production Platform Process swim lane diagram?
Issue 6
Please outline the process for our back-end registry services provider to gain access to the TMCH production environment. 
If this process involves IBM or other external parties please also provide service level expectations so we can include allowance in scheduling of Sunrise and other launch periods
We will let you know when we get a response.

Read previous and future diary entries here.

DotGreen calls it quits with “impossible” gTLD auction looming

DotGreen, the first public and easily most visible applicant for the new gTLD .green, has withdrawn its application, saying it has become “impossible” to continue.
In a statement sent to DI tonight, founder and CEO Annalisa Roger said:

While DotGreen supported the New gTLD program, we believe we exhausted all options within the framework of the New gTLD applicant guidebook and the multi-stakeholder model for procuring .green management. DotGreen remains locked in contention facing an auction among three registry competitors from the Internet industry. Unfortunately it is impossible for DotGreen to proceed within these circumstances.
Today we withdrew DotGreen Community, Inc.’s application for the .green TLD.

DotGreen was founded in 2007 and had built up a small following of supporting environmental organizations. A charitable organization, the plan was to use the proceeds from the registry to fund worthy projects.
A prominent applicant from well before the ICANN application window opened, it held regular eco-themed events during ICANN meetings and even recruited its CFO/COO, Tim Switzer, from its back-end provider, Neustar.
(Switzer is chair of the New gTLD Applicants Group, NTAG, but is expected to resign as a result of the withdrawal.)
But it’s facing competition for .green from portfolio applicants Demand Media, Afilias, and Top Level Domain Holdings.
“It is tough for a single-string applicant,” Roger said. “An auction, sorry, it’s not the appropriate scenario for the .green TLD for several reasons. It really the undermines the authenticity and the faith that the community has put in us and the multi-stakeholder model.”
There’s no way the company could win at auction against three big portfolio applicants, she said.
Despite the company name, DotGreen Community’s application was not a “Community” application under ICANN rules and the only way out of contention was going to be private settlement or auction.
It also faced the uncertainty of Governmental Advisory Committee advice, which had classified the string as requiring extra safeguards for “consumer protection” purposes, causing indefinite delays.
It seems the final decision was financial — the cost of delays and an auction too much for the start-up to bear. It’s a pity really — there was some genuine enthusiasm for the cause behind this bid.
The .green gTLD will now go to which one of the remaining three applicants stumps up the most cash at auction.

More Extended Evaluation passes this week

Four new gTLD applications passed Extended Evaluation this week, and two that were stuck in Initial Evaluation finally made it through, ICANN just revealed.
The Extended Evaluation successes were DotPay’s application for .pay, Commercial Connect’s application for .shop, CompassRose.life’s application for .life and GED Domains’ application for .ged.
The dot-brands .adac (Allgemeiner Deutscher Automobil-Club) and .jio (Affinity Names) passed IE.
Commercial Connect is notable for being 2000-round applicant trying again. It failed on its technical evaluation first time through.