Latest news of the domain name industry

Recent Posts

Lawyer: GoDaddy Whois changes a “critical” contract breach

Kevin Murphy, March 13, 2018, Domain Registrars

GoDaddy is in violation of its ICANN registrar contract by throttling access to its Whois database, according to a leading industry lawyer.

Brian Winterfeldt of the Winterfeldt IP Group has written to ICANN to demand its compliance team enforces what he calls a “very serious contractual breach”.

At issue is GoDaddy’s recent practice, introduced in January, of masking key fields of Whois when accessed in an automated fashion over port 43.

The company no longer shows the name, email address or phone number of its registrants over port 43. Web-based Whois, which has CAPTCHA protection, is unaffected.

It’s been presented as an anti-spam measure. In recent years, GoDaddy has been increasingly accused (wrongly) of selling customer details to spammers pitching web hosting and SEO services, whereas in fact those details have been obtained from public Whois.

But many in the industry are livid about the changes.

Back in January, DomainTools CEO Tim Chen told us that, even as a white-listed known quantity, its port 43 access was about 2% of its former levels.

And last week competing registrar Namecheap publicly complained that Whois throttling was hindering inbound transfers from GoDaddy.

Winterfeldt wrote (pdf) that “nothing in their contract permits GoDaddy to mask data elements, and evidence of illegality must be obtained before GoDaddy is permitted to throttle or deny
port 43 Whois access to any particular IP address”, adding:

The GoDaddy whitelist program has created a dire situation where businesses dependent upon unmasked and robust port 43 Whois access are forced to negotiate wholly subjective terms for access, and are fearful of filing complaints with ICANN because they are reticent to publicize any disruption in service, or because they fear retaliation from GoDaddy…

This is a very serious contractual breach, which threatens to undermine the stability and security of the Internet, as well as embolden other registrars to make similar unilateral changes to their own port 43 Whois services. It has persisted for far too long, having been officially implemented on January 25, 2018. The tools our communities use to do our jobs are broken. Cybersecurity teams are flying blind without port 43 Whois data. And illegal activity will proliferate online, all ostensibly in order to protect GoDaddy customers from spam emails. That is completely disproportionate and unacceptable

He did not disclose which client, if any, he was writing on behalf of, presumably due to fear of reprisals.

He added that his initial outreaches to ICANN Compliance have not proved fruitful.

ICANN said last November that it would not prosecute registrar breaches of the Whois provisions of the Registrar Accreditation Agreements, subject to certain limits, as the industry focuses on becoming compliant with the General Data Protection Regulation.

But GoDaddy has told us that the port 43 throttling is unrelated to GDPR and to the compliance waiver.

Masking Whois data, whether over port 43 or not, is likely to soon become a fact of life anyway. ICANN’s current proposal for GDPR compliance would see public Whois records gutted, with only accredited users (such as law enforcement) getting access to full records.

Registries reject lower fees for anti-abuse prowess

Kevin Murphy, February 16, 2018, Domain Policy

Registries have largely rejected a proposal for them to be offered financial incentives to lower the amount of abuse in their gTLDs.

That’s despite the idea gaining broad support from governments, intellectual property interests and restricted-registration registries.

The concept of ICANN offering discounted fees to registries that proactively fight abuse was floated by the Competition, Consumer Trust, and Consumer Choice Review Team (CCT) back in November.

It recommended in its draft report, among other things:

Consider directing ICANN org, in its discussions with registries, to negotiate amendments to existing Registry Agreements, or in negotiations of new Registry Agreements associated with subsequent rounds of new gTLDs to include provisions in the agreements providing incentives, including financial incentives for registries, especially open registries, to adopt proactive anti-abuse measures.

“Proactive” in this case would mean measures such as preventing known bad actors from registering domains, rather than just waiting for complaints to be filed.

Given that registries have been calling for lower ICANN fees in other instances, one might expect to see support from that constituency.

However, the Registries Stakeholder Group said in a document filed to ICANN’s public comment period on the CCT’s latest recommendations that, it “opposes” the idea of such financial incentives. It said:

The RySG supports recognizing and supporting the many [registry operators] that take steps to discourage abuse, but opposes amending the RA as recommended, to mandate or incentivize ‘proactive’ anti-abuse measures.

The RySG complained that such a system would require lots of complex work to arrive at a definition of abuse and what kinds of measures would qualify as “proactive”.

Even if such definitions could be found, and amendments to the standard RA successfully negotiated, there’s still no guarantee that bad registries would sign up for the incentives or stick to their promises, “resulting in no net improvement to the current situation”, the RySG said.

The group is also concerned that adding more anti-abuse clauses to the RA could increase registries’ risk of liability should they be sued over abuse carried out by their customers.

Not all registries agreed with the RySG position, however.

The informal Verified Top-Level Domains Consortium, which comprises the two registries behind .bank, .insurance and .pharmacy, filed comments supporting the proposal.

It said that gTLDs with vetted eligibility requirements see no abuse but have lower registration volumes and therefore pay higher ICANN fees on a per-domain basis. It said:

ICANN should help to offset these costs to create a more level playing field with high-volume unrestricted registries, i.e., to enhance competition as well as consumer trust. If ICANN made it more financially advantageous to verify eligibility, other registries may be encouraged to adopt this model. The outcome would be the elimination of abuse in these verified TLDs.

Outside of the industry itself, the Governmental Advisory Committee and IP interests such as the Intellectual Property Constituency and INTA, filed comments supporting anti-abuse incentives.

The IPC “strongly” supported the recommendation, but added that the finer details would need to be worked out to ensure that lower ICANN fees did not translate automatically to lower registration fees and therefore more abuse.

Shocking nobody, it added that “abuse” should include intellectual property infringements.

Conversely, the Non-Commercial Stakeholders Group said it “strongly” opposes the recommendation, on the basis that it would push ICANN into a “content policeman” role in violation of its technical mandate:

ICANN is not a US Federal Trade Commission or an anti-fraud unit or regulatory unit of any government. Providing guidance, negotiation and worse yet, financial incentives to ICANN-contracted registries for anti-abuse measures is completely outside of our competence, goals and mandates. Such acts would bring ICANN straight into the very content issues that passionately divide countries — including speech laws, competition laws, content laws of all types. It would invalidate ICANN commitments to ourselves and the global community. It would make ICANN the policemen of the Internet, not the guardians of the infrastructure. It is a role we have sworn not to undertake; a role beyond our technical expertise; and a recommendation we must not accept.

Also opposed to incentivizing anti-abuse measures was the Messaging, Malware and Mobile Anti-Abuse Working Group (an independent entity, not an ICANN working group), which said there’s no data to support such a recommendation.

The reports provide no data that showcase what the implications of altering the economic underpinnings of a highly competitive market may entail, including inadvertent side effects such as registries that already sell low price domains being rewarded with lower ICANN fees. In fact, it may ultimately result in a race to the bottom and higher rates of domain abuse.

Instead, M3AAWG said that ICANN should concentrate is contractual compliance efforts on those registries that the data shows already have large amounts of abuse — presumably meaning the likes of .top, .gdn and the Famous Four Media stable.

ICANN itself filed a comment on the proposal, pointing out that it is not able to unilaterally impose anti-abuse measures into registry agreements.

One imagines that lowering fees at a time when its own budget is under a lot of pressure would probably not be something ICANN would be eager to implement.

These comments and more were summarized in ICANN’s report on the CCT public comment period, published yesterday. The comments themselves can be found here.

The comments feed back into the CCT review team’s work ahead of its final report, which is due to be published some time during Q1.

Under its bylaws, the CCT review is one of the things that ICANN has to complete before it opens the next round of new gTLD applications.

Root crypto rollover now slated for October

Kevin Murphy, February 6, 2018, Domain Tech

ICANN has penciled in October 11 as the new date for rolling the DNS root’s cryptographic keys, a delay of a year from its original plan.

The so-called KSK rollover will see ICANN remove the deprecated 2010 Key Signing Key, leaving only the 2017 KSK active.

The KSK acts as the “trust anchor” for DNSSEC across the whole internet.

After the rollover, any network not configured to use the latest KSK would see a service interruption.

This could mean many millions of internet users being affected, but ICANN doesn’t know the extent of the possible impact for sure.

ICANN told us in November that it knows of 176 organizations in 41 countries, fairly evenly spread across the globe, that are currently not prepared to handle the new KSK.

But its data is patchy because only a tiny number of DNS resolvers are actually configured to automatically report which KSKs they’re set up to use.

Key rollovers are recommended by DNSSEC experts to reduce the risk of brute force attacks against old keys. At the root, the original plan was to roll the keys every five years.

ICANN had named October 11 2017 as the date for the first such rollover, but this was pushed back to some time in the first quarter after ICANN became aware of the lack of support for the 2017 KSK.

This was pushed back again in December to Q3 at the earliest, after ICANN admitted it still didn’t have good enough data to measure the impact of a premature roll.

Since then, ICANN has been engaged in (not always successful) outreach to networks it knows are affected and has kicked off discussions among network operators (there’s a fairly lively mailing list on the topic) to try to gauge how cautious it needs to be.

It’s now published an updated plan that’s the same as the original plan but with a date exactly one year late — October 11, 2018.

Between now and then, it will continue to try to get hold of network operators not ready to use the new keys, but it’s not expecting to completely eliminate damage. The plan reads:

Implicit in the outreach plan is the same assumption that the community had for the earlier (postponed) plan: there will likely be some systems that will fail to resolve names starting on the day of the rollover. The outreach will attempt to minimize the number of affected users while acknowledging that the operators of some resolvers will be unreachable.

The plan is open for public comment and will require the assent of the ICANN board of directors before being implemented. You have until April 2 to respond.

Research finds homograph attacks on big brands rife

Kevin Murphy, January 22, 2018, Domain Tech

Apparent domain name homograph attacks against major brands are a “significant” problem, according to research from Farsight Security.

The company said last week that it scanned for such attacks against 125 well-known brands over the three months to January 10 and found 116,113 domains — almost 1,000 per brand.

Homographs are domains that look like other domains, often indistinguishable from the original. They’re usually used to phish for passwords to bank accounts, retailers, cryptocurrency exchanges, and so on.

They most often use internationalized domain names, mixing together ASCII and non-ASCII characters when displayed in browsers.

To the naked eye, they can look very similar to the original ASCII-only domains, but under the hood they’re actually encoded with Punycode with the xn-- prefix.

Examples highlighted by Farsight include baŋkofamerica.com, amazoṇ.com and fàcebook.com

Displayed as ASCII, those domains are actually xn--bakofamerica-qfc.com, xn--amazo-7l1b.com and xn--fcebook-8va.com.

Farsight gave examples including and excluding the www. subdomain in a blog post last week, but I’m not sure if it double-counted to get to its 116,113-domain total.

As you might imagine, almost all of this abuse is concentrated in .com and other TLDs that were around before 2012, judging by Farsight’s examples. That’s because the big brands are not using new gTLDs for their primary sites yet.

Farsight gave a caveat that it had not generally investigated the ownership of the homograph domains it found. It’s possible some of them are defensive registrations by brands that are already fully aware of the security risk they could present.

GoDaddy and DomainTools scrap over Whois access

Kevin Murphy, January 12, 2018, Domain Registrars

GoDaddy has seriously limited DomainTools’ access to its customers’ Whois records, pissing off DomainTools.

DomainTools CEO Tim Chen this week complained to DI that its access to Whois has been throttled back significantly in recent months, making it very difficult to keep its massive database of domain information up to date.

Chen said that DomainTools is currently only able to access GoDaddy’s Whois over port 43 at about 2% of the rate it had previously.

He said that this has been going on for about six months and that the market-leading registrar has been unresponsive to its requests to have previous levels restored.

“By throttling access to the data by 98% they’re defeating the ability of security practitioners to get data on GoDaddy domains,” Chen said. “It’s particularly troublesome because they [GoDaddy] are such a big part of DNS.”

“We have customers who say the quality of GoDaddy data is just degrading across the board, either through direct look-ups or in some of the DomainTools products themselves,” he said.

DomainTools customers include security professionals trying to hunt down the source of attacks and intellectual property interests trying to locate pirates and cybersquatters.

GoDaddy today confirmed to DI that it has been throttling DomainTools’ Whois access, and said that it’s part of ongoing anti-spam measures.

In recent years there’s been an increase in the amount of spam — usually related to web design, hosting, and SEO — sent to recent domain registrants using email addresses harvested from new Whois records.

GoDaddy, as the market-share leader in retail domain sales, takes a tonne of flak from customers who, unaware of standard Whois practice, think the company is selling their personal information to spammers.

This kind of Twitter exchange is fairly common on GoDaddy’s feed:

While GoDaddy is not saying that DomainTools is directly responsible for this kind of activity, throttling its port 43 traffic is one way the company is trying to counter the problem, VP of policy James Bladel told DI tonight.

“Companies like [DomainTools] present a challenge,” he said. “While we may know these folks, we don’t know who their customers are.”

But that’s just a part of the issue. GoDaddy was also concerned about the amount of resources DomainTools was consuming, and its own future legal responsibilities under the European Union’s forthcoming General Data Protection Regulation.

“When [Chen] says they’re down to a fraction or a percentage of what they had previously, well what they had previously was they were updating and archiving Whois almost in real time,” Bladel said. “And that’s not going to fly.”

“That is not only, we feel, not congruent with our responsibilities to our customers’ data, but it’s also, later on down the road, exactly the kind of thing that GDPR and other regulations are designed to stop,” he said.

GDPR is the EU law that, when it fully kicks in in May, gives European citizens much more rights over the sharing and processing of their private data.

Bladel added that DomainTools is still getting more Whois access than other parties using port 43.

“They have a level of access that is much, much higher than what they would normally have as a registrar,” he said, “but much lower than I think they want, because they want to effectively download and keep current the entirety of the Whois database.”

I’m not getting a sense from GoDaddy that it’s likely to backtrack on its changes.

Indeed, the company also today announced that it from January 25 it will start to “mask” key elements of Whois records when queried over port 43.

GoDaddy told high-value customers such as domainers today that port 43 queries will no longer return the registrant’s first name, last name, email address or phone number.

Bulk Whois users such as registrars (and, I assume, DomainTools) that have been white-listed via the “GoDaddy Port43 Process” will continue to receive full records.

Its web-based Whois, which includes a CAPTCHA gateway to prevent scraping, will continue to function as normal.

Bladel said that these changes are NOT related to GDPR, nor to the fact that ICANN said a couple months back that it would not enforce compliance with Whois provisions of the Registrar Accreditation Agreement, subject to certain conditions.

Big changes at DomainTools as privacy law looms

Kevin Murphy, January 11, 2018, Domain Services

Regular users of DomainTools should expect significant changes to their service, possibly unwelcome, as the impact of incoming European Union privacy law begins to be felt.

Professional users such as domain investors are most likely to be impacted by the changes.

The company hopes to announce how its services will be rejiggered to comply with the General Data Protection Regulation in the next few weeks, probably in February, but CEO Tim Chen spoke to DI yesterday in general terms about the law’s possible impact.

“There will be changes to the levels of service we offer currently, especially to any users of DomainTools that are not enterprises,” Chen said.

GDPR governs how personal data on EU citizens is captured, shared and processed. It deals with issues such as customer consent, the length of time such data may be stored, and the purposes for which it may be processed.

Given that DomainTools’ entire business model is based on capturing domain registrants’ contact information without their explicit consent, then storing, processing and sharing that data indefinitely, it doesn’t take a genius to work out that the new law represents a possibly existential threat.

But while Chen says he’s “very concerned” about GDPR, he expects the use cases of his enterprise customers to be protected.

DomainTools no longer considers itself a Whois company, Chen said, it’s a security services company now. Only about 20% of its revenue now comes from the $99-a-month customers who pay to access services such as reverse Whois and historical Whois queries.

The rest comes from the 500-odd enterprise customers it has, which use the company’s data for purposes such as tracking down network abuse and intellectual property theft.

DomainTools is very much aligned here with the governments and IP lawyers that are pressing ICANN and European data protection authorities to come up with a way Whois data can still be made available for these “legitimate purposes”.

“We’re very focused on our most-important goal of making sure the cyber security and network security use cases for Whois data are represented in the final discussions on how this legislation is really going to land,” he said.

“There needs to be some level of access that is retained for uses that are very consistent with protecting the very constituents that this legislation is trying to protect from a privacy perspective,” he said.

The two big issues pressing on Chen’s mind from a GDPR perspective are the ability of the company to continue to aggregate Whois records from hundreds of TLDs and thousands of registrars, and its ability to continue to provide historical, archived Whois records — the company’s most-popular product after vanilla Whois..

These are both critical for customers responding to security issues or trying to hunt down serial cybersquatters and copyright infringers, Chen said.

“[Customers are] very concerned, because their ability to use this data as part of their incident response is critical, and the removal of the data from that process really does injure their ability to do their jobs,” he said.

How far these use cases will be protected under GDPR is still an open question, one largely to be determined by European DPAs, and DomainTools, like ICANN the rest of the domain industry, is still largely in discussion mode.

“Part of what we need to help DPAs understand is: how long is long enough?” Chen said. “Answering how long this data can be archived is very important.”

ICANN was recently advised by its lawyers to take its case for maintaining Whois in as recognizable form as possible to the DPAs and other European privacy bodies.

And governments, via the Governmental Advisory Committee, recently urged ICANN to continue to permit Whois access for “legitimate purposes”.

DomainTools is in a different position to most of the rest of the industry. In terms of its core service, it’s not a contracted party with ICANN, so perhaps will have to rely on hoping whatever the registries and registrars work out will also apply to its own offerings.

It’s also different in that it has no direct customer relationship with the registrants whose data it processes, nor does it have a contractual relationship with the companies that do have these customer relationships.

This could make the issue of consent — the right of registrant to have a say in how their data is processed and when it is deleted — tricky.

“We’re not in a position to get consent from domain owners to do what we do,” Chen said. “I think where we need to be more thoughtful is whether DomainTools needs to have a process where people can opt out of having their data processed.”

“When I think about consent, it’s not on the way in, because we just don’t have a way to do that, it’s allowing a way out… a mechanism where people can object to their data being processed,” he said.

How DomainTools’ non-enterprise customers and users will be affected should become clear when the company outlines its plans in the coming weeks.

But Chen suggested that most casual users should not see too much impact.

“The ability of anyone who has an interest in using Whois data, who needs it every now and then, for looking up a Whois record of a domain because they want to buy it as a domain investor for example, that should still be very possible after GDPR,” he said.

“I don’t think GDPR is aimed at individual, one-at-a-time use cases for data, I think it’s aimed at scalable abuse of the data for bad purposes,” he said.

“If you’re running a business in domain names and you need to get Whois at significant scale, and you need to evaluate that many domains for some reason, that’s where the impact may be,” he said.

Disclosure: I share a complimentary DomainTools account with several other domain industry bloggers.

New Trump appointee slams ICANN after security group shutdown

Kevin Murphy, December 19, 2017, Domain Policy

Not even a month into the job, the US official with most direct responsibility over domain name policy has criticized ICANN for shutting down a security working group.

David Redl, the new assistant secretary at the National Telecommunications and Information Administration, wrote to ICANN (pdf) last week to complain about its board unilaterally shutting down, temporarily, its supposedly independent Security, Stability and Resiliency of the DNS Review team.

He wrote that the action “calls into question” ICANN’s commitment to transparency and accountability, writing:

Everything documented to date about these reviews stresses the importance of openness, transparency and community consultation. Unfortunately, it seems that with the October 28th action, the ICANN Board violated these principles by substituting its judgement for that of the community.

SSR-2, as it is known, is one of the reviews previously mandated by ICANN’s Affirmation of Commitments with the US government (via the NTIA) but which can now be found instead embedded in its bylaws.

The ICANN board of directors temporarily suspended it in October, something like a soft reboot, after growing concerned that it was stepping outside of its mandate and that its members lacked expertise.

The move attracted broad criticism and it would be disingenuous of me to suggest that Redl’s position is a controversial one — you’d be hard pressed to find any section of the community that wholeheartedly supports the board’s action.

Indeed, the US representative to the Governmental Advisory Committee voiced similar concerns at the ICANN meeting in Abu Dhabi in late October, prior to Redl’s confirmation to the NTIA job.

Redl took the post November 21, having been nominated by Donald Trump back in May, replacing Obama appointee Larry Strickling, who left the agency in January.

He’s the first NTIA chief since ICANN’s inception not to enjoy the special position of power over ICANN granted by the old IANA contract, which was scrapped in September 2016.

Concern as ICANN shuts down “independent” security review

Kevin Murphy, October 31, 2017, Domain Policy

Just a year after gaining its independence from the US government, ICANN has come under scrutiny over concerns that its board of directors may have overstepped its powers.

The board has come in for criticism from almost everyone expressing an opinion at the ICANN 60 meeting in Abu Dhabi this week, after it temporarily suspended a supposedly independent security review.

The Security, Stability and Resiliency of the DNS Review, known as SSR-2, is one of the mandatory reviews that got transferred into ICANN’s bylaws after the Affirmation of Commitments with the US wound up last year.

The review is supposed to look at ICANN’s “execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes, both internal and external, that directly affect and/or are affected by the Internet’s system of unique identifiers that ICANN coordinates”.

The 14 to 16 volunteer members have been working for about eight months, but at the weekend the ICANN board pulled the plug, saying in a letter to the review team that it had decided “to suspend the review team’s work” and said its work “should be paused”.

Chair Steve Crocker clarified in sessions over the weekend and yesterday that it was a direction, not a request, but that the pause was merely “a moment to take stock and then get started again”.

Incoming chair Cherine Chalaby said in various sessions today and yesterday that the community — which I take to mean the leaders of the various interest groups — is now tasked with un-pausing the work.

Incoming vice-chair Chris Disspain told community leaders in an email (pdf) yesterday:

The Board has not usurped the community’s authority with respect to this review. Rather, we are asking the SOs and ACs to consider the concerns we have heard and determine whether or not adjustments are needed. We believe that a temporary pause in the SSR2 work while this consideration is under way is a sensible approach designed to ensure stakeholders can reach a common understanding on the appropriate scope and work plan

Confusion has nevertheless arise among community members, and some serious concerns and criticisms have been raised by commercial and non-commercial interests — including governments — over the last few days in Abu Dhabi.

But the board’s concerns with the work of SSR-2 seem to date back a few months, to the Johannesburg meeting in June, at which Crocker said “dangerous signals” were observed.

It’s not clear what he was referring to there, but the first serious push-back by ICANN came earlier this month, when board liaison Kaveh Ranjbar, apparently only appointed to that role in June, emailed the group to say it was over-stepping its mandate.

Basically, the SSR-2 group’s plan to carry out a detailed audit of ICANN’s internal security profile seems to have put the willies up the ICANN organization and board.

Ranjbar wrote:

The areas the Board is concerned with are areas that indeed raise important organizational information security and organizational oversight questions. However, these are also areas that are not segregated for community review, and are the responsibility of the ICANN Organization (through the CEO) to perform under the oversight of the ICANN Board.

While we support the community in receiving information necessary to perform a full and meaningful review over ICANN’s SSR commitments, there are portions of the more detailed “audit” plan that do not seem appropriate for in-depth investigation by the subgroup. Maintaining a plan to proceed with detailed assessments of these areas is likely to result in recommendations that are not tethered to the scope of the SSR review, and as such, may not be appropriate for Board acceptance when recommendations are issued. This also can expand the time and resources needed to perform this part of the review.

This does not seem hugely unreasonable to me. This kind of audit could be expensive, time-consuming and — knowing ICANN’s history of “glitches” — could have easily exposed all kinds of embarrassing vulnerabilities to the public domain.

Ranjbar’s letter was followed up a day later with a missive (pdf) from the chair of ICANN’s Security and Stability Advisory Committee, which said the SSR-2’s work was doomed to fail.

Patrick Falstrom recommended a “temporarily halt” to the group’s work. He wrote:

One basic problem with the SSR2 work is that the review team seems neither to have sufficient external instruction about what to study nor to have been able to formulate a clear direction for itself. Whatever the case, the Review Team has spent hundreds of hours engaged in procedural matters and almost no progress has been made on substantive matters, which in turn has damaged the goodwill and forbearance of its members, some of whom are SSAC members. We are concerned that, left to its own devices, SSR2 is on a path to almost certain failure bringing a consequential loss of credibility in the accountability processes of ICANN and its community.

Now that ICANN has actually acted upon that recommendation, there’s concern that it sets a disturbing precedent for the board taking “unilateral” action to scupper supposedly independent accountability mechanisms.

The US government itself expressed concern, during a session between the board and the Governmental Advisory Committee in Abu Dhabi today.

“This is unprecedented,” US GAC rep Ashley Heineman said. “I just don’t believe it was ever an expectation that the ICANN board would unilaterally make a decision to pause or suspend this action. And that is a matter of concern for us.”

“It would be one thing if it was the community that specifically asked for a pause or if it was a review team that says ‘Hey, we’re having issues, we need a pause.’ What’s of concern here is that ICANN asked for this pause,” she said.

UK GACer Mark Carvell added that governments have been “receiving expressions of grave concern” about the move and urged “maximum transparency” as the SSR-2 gets back on track.

Jonathan Zuck of the Innovators Network Foundation, one of the volunteers who worked on ICANN’s transition from US government oversight, also expressed concern during the public forum session yesterday.

“I think having a fundamental accountability mechanism unilaterally put on hold is something that we should be concerned about in terms of process,” he said. “I’m not convinced that it was the only way to proceed and that from a precedential standpoint it’s not best way to proceed.”

Similar concerns were voiced by many other parts of the community as they met with the ICANN board throughout today and yesterday.

The problem now is that the bylaws do not account for a board-mandated “pause” in a review team’s work, so there’s no process to “unpause” it.

ICANN seems to have got itself tangled up in a procedural quagmire — again — but sessions later in the week have been scheduled in order for the community to begin to untangle the situation.

It doubt we’ll see a resolution this week. This is likely to run for a while.

Over 750 domains hijacked in attack on Gandi

Gandi saw 751 domains belonging to its customers hijacked and redirected to malware delivery sites, the French registrar reported earlier this month.

The attack saw the perpetrators obtain Gandi’s password for a gateway provider, which it did not name, that acts as an intermediary to 34 ccTLD registries including .ch, .se and .es.

The registrar suspects that the password was obtained by the attacker exploiting the fact that the gateway provider does not enforce HTTPS on its login pages.

During the incident, the name servers for up up to 751 domains were altered such that they directed visitors to sites designed to compromise unpatched computers.

The redirects started at 0804 UTC July 7, and while Gandi’s geeks had reversed the changes by 1615 it was several more hours before the changes propagated throughout the DNS for all affected domains.

About the theft of its password, Gandi wrote:

These credentials were likewise not obtained by a breach of our systems and we strongly suspect they were obtained from an insecure connection to our technical partner’s web portal (the web platform in question allows access via http).

It’s not clear why a phishing attack, which would seem the more obvious way to obtain a password, was ruled out.

Gandi posted a detailed timeline here, while Swiss registry Switch also posted an incident report from its perspective here. An effected customer, which just happened to be a security researcher, posted his account here.

Gandi says it manages over 2.1 million domains across 730 TLDs.

GoDaddy launches security service after Sucuri acquisition

GoDaddy has revealed the first fruits of its March acquisition of web security service provider Sucuri.

It’s GoDaddy Website Security, what appears to be a budget version of the services Sucuri already offers on a standalone basis.

For $6.99 per month ($83.88/year), the service monitors your web site for malware and removes it upon request. It also keeps tabs on major blacklists to make sure you’re not being blocked by Google, Norton or McAfee.

This low-end offering gets you a 12-hour response time for the cleanup component. You can up that to 30 minutes by taking out the $299.99 per year plan.

The more expensive plan also includes DDoS protection, a malware firewall and integration with a content delivery network for performance.

There’s also an intermediate, $19.99-per-month ($239.88/year) plan that includes the extra features but keeps the response time at 12 hours.

An SSL certificate is included in the two more-expensive packages.

The pricing and feature set looks to compare reasonably well with Sucuri’s standalone products, which start at $16.66 a month and offer response times as fast as four hours.

As somebody who has suffered from three major security problems on GoDaddy over the last decade or so, and found GoDaddy’s response abysmal on all three occasions (despite my generally positive views of its customer service), the new service is a somewhat tempting proposition.