Go Daddy selling domains door-to-door in India

Door-to-door sales have helped Go Daddy grow its Indian business by 86%, according to a company press release.
The market-leading registrar said today that the remarkable growth has come since it launched a customer support center in Hyderabad a year ago.
It’s taken 250,000 calls since then, Go Daddy said.
The company also pointed to some unconventional sales techniques:

Since launching on the ground in India, GoDaddy has connected with customers in a very personal way. A prime example is the recent “Cup of Coffee” campaign that demystified the process of leveraging the Internet by providing actual door-to-door demonstrations to show small businesses exactly how to get online. Professionally trained GoDaddy experts and GoDaddy Resellers engaged with prospective clients to demonstrate how beautiful websites can be built quickly. These personalized initiatives have helped fuel GoDaddy’s unprecedented growth.

Go Daddy’s reseller network in India has grown 88% since last year, the company added.

1 Comment Tagged: go daddy

Name collisions comments call for more gTLD delay

The first tranche of responses to Interisle Consulting’s study into the security risks of new gTLDs, and ICANN’s proposal to delay a few hundred strings pending more study, is in.
Comments filed with ICANN before the public comment deadline yesterday fall basically into two camps:

• Non-applicants (mostly) urging ICANN to proceed with extreme caution. Many are asking for more time to study their own networks so they can get a better handle on their own risk profiles.
• Applicants shooting holes in Interisle’s study and ICANN’s remeditation plan. They want ICANN to reclassify everything except .home and .corp as low risk, removing delays to delegation and go-live.

They were responding to ICANN’s decision to delay 521 “uncalculated risk” new gTLD applications by three to six months while further research into the risk of name collisions — where a new gTLD could conflict with a TLD already used by internet users in a non-standard way — is carried out.
Proceed with caution
Many commenters stated that more time is needed to analyse the risks posed by name collisions, noting that Interisle studied primarily the volume of queries for non-existent domains, rather than looking deeply into the consequences of delegating colliding gTLDs.
That was a point raised by applicants too, but while applicants conclude that this lack of data should lead ICANN to lift the current delays, others believe that it means more delays are needed.
Two ICANN constituencies seem to generally agree with the findings of the Interisle report.
The Internet Service Providers and Connectivity Providers constituency asked for the public comment period be put on hold until further research is carried out, or for at least 60 days. It noted:

corporations, ISPs and connectivity providers may bear the brunt of the security and customer-experience issues resulting from adverse (as yet un-analyzed) impacts from name collision
…
these issues, due to their security and customer-experience aspects, fall outside the remit of people who normally participate in the ICANN process, requiring extensive wide-ranging briefings even in corporations that do participate actively in the ICANN process

The At-Large Advisory Committee concurred that the Interisle study does not currently provide enough information to fully gauge the risk of name collisions causing harm.
ALAC said it was “in general concurrence with the proposed risk mitigation actions for the three defined risk categories” anyway, adding:

ICANN must assure that such residual risk is not transferred to third parties such as current registry operators, new gTLD applicants, registrants, consumers and individual end users. In particular, the direct and indirect costs associated with proposed mitigation actions should not have to be borne by registrants, consumers and individual end users. The Board must err on the side of caution

Several individual stakeholders agreed with the ISPCP that they need more time to look at their own networks. The Association of Nation Advertisers said:

Our member companies are working diligently to determine if DNS Clash issues are present within their respective networks. However the ANA had to communicate these issues to hundreds of companies, after which these companies must generate new data to determine the potential service failures on their respective networks.

The ANA wants the public comment period extended until November 22 to give its members more time to gather data.
While the ANA can always be relied upon to ask for new gTLDs to be delayed, its request was echoed by others.
General Electric called for three types of additional research:

• Additional studies of traffic beyond the initial DITL sample.
• Information and analysis of “use cases” — particular types of queries and traffic — and the consequences of the failure of particular use cases to resolve as intended (particular use cases could have severe consequences even if they might occur infrequently — like hurricanes), and
• Studies of the time and costs of mitigation.

GE said more time is needed for companies such as itself to conduct impact analyses on their own internal networks and asked ICANN to not delegate any gTLD until the risk is “fully understood”.
Verizon, Heinz and the American Insurers Association have asked for comment deadline extensions for the same reasons.
The Association of Competitive Technology (which has Verisign as a member) said:

ICANN should slow or temporarily suspend the process of delegating TLDs at risk of causing problems due to their frequency of appearance in queries to the root. While we appreciate the designation of .home and .corp as high risk, there are many other TLDs which will also have a significant destructive effect.

Numerically, there were far more comments criticizing ICANN’s mitigation proposal. All were filed by new gTLD applicants, whose interests are aligned, however.
Most of these comments, which are far more focused on the details and the data, target perceived deficiencies in Interisle’s report and ICANN’s response to it.
Several very good arguments are made.
The Svalbard problem
First, there is criticism of the cut-off point between “low risk” and “uncalculated risk” strings, which some applicants say is “arbitrary”.
That’s mostly true.
ICANN basically took the list of applied-for strings, ordered by the frequency Interisle found they generate NXDOMAIN responses at the root, and drew a line across it at the 49,842 queries mark.
That’s because 49,842 queries is what .sj, the least-frequently-queried real TLD, received over the same period
If your string, despite not yet existing as a gTLD, already gets more traffic than .sj, it’s classed as “uncalculated risk” and faces more delays, according to ICANN’s plan.
As Directi said in its comments:

The result of this arbitrary selection is that .bio (Rank 281) with 50,000 queries (rounded to the nearest thousand) is part of the “uncategorized risk” list, and is delayed by 3 to 6 months, whereas .engineering (Rank 282) with 49,000 queries (rounded to the nearest thousand) is part of the “low risk” list, and can proceed without any significant delays.

What neither ICANN nor Interisle explained is why this is an appropriate place to draw a line in the sand.
This graphic from DotCLUB Domains illustrates the scale of the problem nicely:
.sj is the ccTLD for Svalbard, a Norwegian territory in the Arctic Circle with fewer than 3,000 inhabitants. The TLD is administered by .no registry Norid, but it’s not possible to register domains there.
Does having more traffic than .sj mean a gTLD is automatically more risky? Does having less mean a gTLD is safe? The ICANN proposal assumes “yes” to both questions, but it doesn’t explain why.
Many applicants say that having more traffic than existing gTLDs does not automatically mean your gTLD poses a risk.
They pointed to Verisign data from 2006, which shows that gTLDs such as .xxx and .asia were already receiving large amounts of traffic prior to their delegation. When they were delegated, the sky did not fall. Indeed, there were no reports of significant security and stability problems.
The New gTLD Applicants Group said:

In fact, the least “dangerous” current gTLD on the chart, .sx, had 331 queries per million in 2006. This is a higher density of NXDOMAIN queries than all but five proposed new TLDs. 4 Again, .sx was launched successfully in 2012 with none of the problems predicted in these reports.
These successful delegations alone demonstrate that there is no need to delay any more than the two most risky strings.

Donuts said:

There is no factual basis in the study recommending halting delegation process of 20% of applied-for strings. As the paper itself says, “The Study did not find enough information to properly classify these strings given the short timeline.” Without evidence of actual harm, the TLDs should proceed to delegation. Such was the case with other TLDs such as .XXX and .ASIA, which were delegated without delay and with no problems post-delegation.

Applicants also believe that the release in June 2012 of the list of all 1,930 applied-for strings may have skewed the data set that Interisle used in its study.
Uniregistry, for example, said:

The sole fact that queries are being received at the root level does not itself present a security risk, especially after the release to the public of the list of applied-for strings.

The argument seems to be that a lot of the NXDOMAIN traffic seen in 2013 is due to people and software querying applied-for TLDs to see if they’re live yet.
It’s quite a speculative argument, but it’s somewhat supported by the fact that many applied-for strings received more queries in 2013 than they did in the equivalent 2012 sampling.
Second-level domains
Some applicants pointed out that there may not be a correlation between the volume of traffic a string receives and the number of second-level domains being queried.
A string might get a bazillion queries for a single second-level domain name. If that domain name is reserved by the registry, the risk of a name collision might be completely eliminated.
The Interisle report did show that number of SLDs and the volume of traffic do not correlate.
For example, .hsbc is ranked 14th in terms of traffic volume but saw requests for just 2,000 domains, whereas .inc, which ranked 15th, saw requests for 73,000 domains.
Unfortunately, the Interisle report only published the SLD numbers for the top 35 strings by query volume, leaving most applicants none the wiser about the possible impact of their own strings.
And ICANN did not factor the number of SLDs into its decision about where to draw the line between “low” and “uncalculated” risk.
Conspiracy theories
Some applicants questioned whether the Interisle data itself was reliable, but I find these arguments poorly supported and largely speculative.
They propose that someone (meaning presumably Verisign, which stands to lose market share when new gTLDs go live, and which kicked off the name collisions debate in the first place) could have gamed the study by generating spurious requests for applied-for gTLDs during the period Interisle’s data was being captured.
Some applicants put forth this view, while other limited their comments to a request that future studies rely only on data collected before now, to avoid tampering at the point of collection in future.
NTAG said:

Query counts are very easily gamed by any Internet connected system, allowing for malicious actors to create the appearance of risk for any string that they may object to in the future. It would be very easy to create the impression of a widespread string collision problem with a home Internet connection and the abuse of the thousands of available open resolvers.

While this kind of mischief is a hypothetical possibility, nobody has supplied any evidence that Interisle’s data was manipulated by anyone.
Some people have privately pointed DI to the fact that Verisign made a substantial donation to the DNS-OARC — the group that collected the data that Interisle used in its study — in July.
The implication is that Verisign was somehow able to manipulate the data after it was captured by DNS-OARC.
I don’t buy this either. We’re talking about a highly complex 8TB data set that took Interisle’s computers a week to process on each pass. The data, under the OARC’s deal with the root server operators, is not allowed to leave its premises. It would not be easily manipulated.
Additionally, DNS-OARC is managed by Internet Systems Consortium — which runs the F-root and is Uniregistry’s back-end registry provider — from its own premises in California.
In short, in the absence of any evidence supporting this conspiracy theory, I find the idea that the Interisle data was hacked after it was collected highly improbable.
What next?
I’ve presented only a summary of some key points here. The full list of comments can be found here. The reply period for comments closes September 17.
Several ICANN constituencies that can usually be relied upon to comment on everything (registrars, intellectual property, business and non-commercial) have not yet commented.
Will ICANN extend the deadline? I suppose it depends on how cautious it wants to be, whether it believes the companies requesting the extension really are conducting their own internal collision studies, and how useful it thinks those studies will be.

Comment Tagged: ICANN, name collision, new gTLDs, security, verisign

Roussos loses last .music LRO

Constantine Roussos’ DotMusic Ltd has lost its seventh and final Legal Rights Objection against rival .music applicants.
In the decision in DotMusic Ltd v DotMusic Inc, published (pdf) this hour, WIPO panelist Mark Partridge ruled:

the Panel is compelled to conclude that the Objector lacks enforceable rights. The term “.music” (or “dotMusic”) would in the Panel’s opinion be recognized as a generic designation for a top-level domain name directed at or relating to music and music-related services. As a result, the Panel is of the opinion that the Objector cannot own trademark rights in the terms “.music” (or “dotMusic”) per se as a matter of law, even if it has developed awareness of that term as being associated with it as the name of an entity.

That’s roughly in keeping with the first six DotMusic decisions and a not remotely surprising result.
The objections phase for .music is not over yet, however. There are still seven Community Objections pending, most of them filed by American Association of Independent Music, which is affiliated with Roussos’ bid.
There’s also the possibility that DotMusic and/or .music LLC (which also has industry backing) could apply for a Community Priority Evaluation, which would kill off all rivals at a stroke.
I’ve yet to hear a convincing argument why either application could win a CPE, so my guess is that .music is, eventually, heading to auction.

58 Comments Tagged: .music, dotmusic, ICANN, legal rights objection, new gTLDs, wipo

dotShabaka Diary — Day 7, PDT Success

ICANN today revealed that three of the first four new gTLD applicants to have already signed registry contracts have also now passed through pre-delegation testing.
He’s the take of dotShabaka, one of the three, written by general manager Yasmin Omer as the seventh installment of our ongoing dotShabaka Diary.

Tuesday 27 August 2013
A milestone today with the receipt of official confirmation from ICANN that شبكة. has successfully passed pre-delegation testing.
While effectively it’s just a piece of paper (or more accurately a PDF file) it is, like the execution of the Registry Agreement, another step closer to making the new gTLD program a reality. We would like to extend our thanks to the support of the technical team at ARI Registry Services, the team at IIS and ICANN for playing your part in getting us to this stage.
Like many pioneers the path has not been easy; however with the support of all involved we have achieved the desired outcome. We hope that through our experience we are helping to refine the process, making the journey easier for those to follow.
شبكة. is now eligible for transition to IANA delegation. We expect notice soon from ICANN on how to proceed with this step. The next tasks to be completed include TMCH Integration Testing. This is slated to commence on 9 September 2013 when the claims service functionality becomes available.
At this point we are on schedule for Sunrise and despite the trials that we and every applicant has faced in the past, we remember the words of Egyptian singer, songwriter, and film actress Om Kalthoum:
“أحب رؤية القمر في بدايته عندما يكون هلال لأنني أحب كل شيء له مستقبل”
“I love looking at the moon when it’s still a crescent because I love everything that has a future”

Comment Tagged: dotshabaka diary

All gTLD confusion decisions in one handy chart

Dirk Krischenowski of DotBerlin has produced an interesting chart plotting all the new gTLD string confusion decisions to come out of ICANN and its objection panels to date.
He’s kindly allowed us to reproduce it here. Click to enlarge.

Each string-pair’s percentage of similarity, as determined by the Sword algorithm, determines its position on the Y-axis, while the color of the circle indicates which way the decision went.
It’s a nice way of visualizing the fact that while Sword may have been instructive in the String Similarity Panel’s determinations it’s not an overwhelming factor in String Confusion Objection decisions made by International Centre for Dispute Resolution panelists.
You can download the chart as a PDF here.

2 Comments Tagged: dotberlin, ICANN, icdr, string confusion objection, string similarity panel

ICANN’s name collision plan “creates risk of abuse”

One of ICANN’s proposed methods of reducing the risk of name collisions in new gTLDs actually may create its own “significant risk for abuse”, according to RIPE NCC.
Asking registry operators to send a notification to the owner of IP address blocks that have done look-ups of their TLD before it is delegated risks creating a “backlash” against ICANN and registry operators, RIPE said.
Earlier this month, ICANN said that for the 80% of applied-for strings that are categorized as low risk, “the registry operator will notify the point of contacts of the IP addresses that issue DNS requests for an un-delegated TLD or names under it.”
The proposal is intended to reduce the risk of harms caused by the collision of new gTLDs and matching names that are already in use on internal networks.
For example, if the company given .web discovers that .web already receives queries from 100 different IP blocks, it will have to look up the owners of those blocks with the Regional Internet Registries and send them each an email telling them than .web is about to hit the internet.
RIPE is the RIR for Europe, responsible for allocating IP addresses in the region, so its view on how effective a mitigation plan this is cannot be easily shrugged off.
Chief scientist Daniel Karrenberg told ICANN today that the complexity of the DNS, with its layers of recursive name servers and such, makes the approach pointless:

The notifications will not be effective because they will typically not reach the party that is potentially at risk.

In addition, it will be trivial for mischief-makers to create floods of useless notifications by conducting deliberately erroneous DNS queries for target TLDs, he said:

anyone can cause the registry operator to send an arbitrary amount of mandatory notifications to any holder of IP address space. It will be highly impractical to detect such attacks or find their source by technical means. On the other hand there are quite a number of motivations for such an attack directed at the recipient or the sender of the notifications. The backlash towards the registry operator, ICANN and other parties in the chain will be even more severe once the volume increases and when it turns out that the notifications are for “non-existing” queries.

With a suitably large botnet, it’s easy to see how an attacker could generate the need for many thousands of mandatory notifications.
If the registry has a manual notification process, such a flood would effectively DDoS the registry’s ability to send the notices, potentially delaying the gTLD.
Even if the process were to be automated, you can imagine how IP address block owners (network admins at ISPs and hosting companies, for example) would respond to receiving notifications, each of which creates work, from hundred of affected gTLD operators.
It’s an interesting view, and one that affected new gTLD applicants (which is most of them) will no doubt point to in their own comments on the name collisions mitigation plan.

Comment Tagged: ICANN, name collisions, new gTLDs, ripe ncc, security

15 new gTLD applications enter Extended Evaluation

The first batch of new gTLD applications have officially entered the Extended Evaluation stage of the process.
Fifteen bids that failed to achieve passing scores during Initial Evaluation are now taking a second crack at getting approved.
Extended Evaluation is voluntary but in most cases — such as when additional financial or geographic support information is required — it is also free from additional ICANN fees.
If an application goes into EE, its whole contention set is delayed — possibly for months — while the evaluation is completed.
The affected strings so far are: .online, .bcg, .ged, .supersport, .life, .payu, .locus, .shop, .taipei, .pay, .ltd, .olayangroup, .llc, العليان., and .mckinsey.
The 15 comprise basically every application that has so far been told it is eligible for extended evaluation, but excluding most of those that received the news last Friday.
The DI PRO Application Tracker has been updated to reflect the new statuses, and we’ve added a new search option that lets you view or exclude “In EE” applications.
The DI PRO New gTLD Timeline now also includes diary entries related to Extended Evaluation.

Comment Tagged: extended evaluation, ICANN, initial evaluation, new gTLDs

.taipei not blocked after all

Taipei City Government’s application for the .taipei new gTLD is still live, despite indications to the contrary from ICANN last week.
On Friday, we reported that there was some confusion about the status of the bid, which was flagged by ICANN as “Eligible for Extended Evaluation” in one place and “Ineligible for Further Review” in another.
We wondered aloud whether Taiwan’s controversial national identity was responsible for the application failing due to lack of governmental support.
But an ICANN spokesperson called last night to confirm that the “Eligible” status is the correct one. The ICANN web site has been corrected accordingly.
What this means is that .taipei is not rejected yet, but must provide more evidence of government support if it wants to pass Extended Evaluation and eventually get delegated.
The question remains, however: which government are we talking about here? If it’s the People’s Republic of China, which claims Taiwan as a province, Taipei may still face problems.

Comment Tagged: .taipei, ICANN, new gTLDs

CNNIC hit by “largest ever” denial of service attack

Chinese ccTLD operator CNNIC suffered up to half a day of degraded performance and intermittent accessibility yesterday, after being hit by what it called its “largest ever” denial of service attack.
CNNIC is one of ICANN’s three Emergency Back-End Registry Operators, contracted to take over the running of any new gTLD registries that fail. It’s also the named back-end for seven new gTLD applications.
According to an announcement on its web site, as well as local reports and tips to DI, the first wave of DDoS hit it at about midnight yesterday. A second wave followed up at 4am local time and lasted up to six hours.
According to a tipster, all five of .cn’s name servers were inaccessible in China during the attack.
Local reports (translated) say that many Chinese web sites were also inaccessible to many users, but the full scale of the problem doesn’t seem to be clear yet.
China’s .cn is the fourth-largest ccTLD, with close to 10 million domains under management.

Comment Tagged: cnnic, ddos, ebero, ICANN, new gTLDs

dotShabaka Diary — Day 6, TMCH Integration Testing

Today, the sixth 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.

Monday 26 August 2013
We attended the second IBM webinar on the TMCH which ran smoothly. The guys at IBM were pretty responsive and helpful.
Having received our registration token from ICANN, we logged on to the TMDB System to create credentials for the OT&E platform, provide contact details and accept the TMCH Terms and Conditions. TMCH integration testing is now on hold since we were not able to download the DNL file or upload the LORDN file. IBM confirmed that this functionality will not be available until the Trademark Claims functionality update scheduled for the 9th of September.
The testing environment was communicated as the TMCH accreditation environment that would include all the functionality required for Sunrise processing. It’s currently a limited test environment but we’re looking forward to conducting further tests as IBM continue to add functionality.
We recommend those planning on conducting TMCH Integration Testing in the near future wait until the Claims functionality update scheduled for the 9th of September before proceeding.

Read previous and future diary entries here.

Comment Tagged: dotshabaka diary