Freenom hit by FIFTH ICANN action after litany of screw-ups

Is time up for Freenom? After being sued by Facebook and losing its contracts to operate ccTLDs for at least two countries, now it also has ICANN Compliance to deal with.

Its registrar arm, Netherlands-based OpenTLD, has been hit with a lengthy ICANN breach notice that alleges the company failed to allow its customers to renew and/or transfer their domains, in violation of the registrar contract.

It’s the fifth time OpenTLD has been targeted by Compliance, following breach notices in 2020, 2017 and 2015 and a notice of suspension later in 2015. ICANN says this notice is for the same sorts of failures as in 2020 and 2017.

The latest notice covers a dozen separate cases, probably the largest number in a single breach notice to date. Some of them ICANN has been investigating as far back as January 2022.

The notice says that OpenTLD failed to allow some registrants of expired domains to recover their names under the Expired Registration Recovery Policy and that some registrants were not provided with the AuthInfo codes they need to transfer their domains to other registrars upon request, which registrars have to do under the Transfer Policy.

It goes on to describe a situation where the registrar habitually did not respond to Compliance’s calls, emails or faxes.

OpenTLD apparently has not filed its 2022 Compliance Certificate with ICANN either, which it was supposed to do before January 20 this year.

The company had almost 19,000 gTLD domain names under management at the end of May, down from a 2019 peak of almost 45,000, but it’s probably better known for being Freenom, the registry behind .ml, .ga, .cf, .gq and .tk.

Domains in these five ccTLDs — mostly representing West African nations suffering under military dictatorships or civil war — were offered for free and monetized by the registry upon expiration or suspension.

But Freenom has not offered new regs in these TLD since the start of the year. Its web site blames technical problems, but it’s widely believed to be a result of the cyberquatting lawsuit filed by Facebook owner Meta in late 2022.

Mali and Gabon, of .ml and .ga, have since severed ties with Freenom. It turned out .ga had seven million domains in its zone, most of which presumably belonged to the registry.

OpenTLD has until October 11 to give ICANN evidence that it followed policy with the renewals or transfers of dozens of names domains or risk losing its accreditation.

ICANN finally cans Net 4 India

iCANN has terminated Net 4 India’s registrar accreditation, after many months of criticism and foot-dragging and a recent sharp uptick in customer complaints.

The move comes after an unprecedented four concurrent public breach notices over 20 months, almost four years after the company entered insolvency proceedings — grounds for termination which ICANN became aware of almost two years ago.

ICANN has received over 2,600 customer complaints over the last year, and almost 1,000 of these were submitted in February alone, according to the organization.

“The termination of the RAA is due to Net 4 India’s repeated and consistent breaches of the RAA and failure to cure such breaches despite multiple notices from ICANN and opportunity to cure,” ICANN said in its ginormous 59-page execution warrant (pdf).

Among the charges ICANN levels at Net4 is its failure to operate a functioning Whois service, something it’s warned the company about 30 times since November.

This hindered ICANN’s ability to investigate the more serious charges — that Net4 transferred some of its customers’ domains to a different registrar, OpenProvider, without their knowledge or consent, in violation of ICANN transfer policies.

The registrar also failed to enable its customers to renew their expired domains or transfer them to other registrars, also in violation of binding policy, ICANN said.

ICANN said:

Currently, more than 400 cases remain unresolved; and hundreds of complaints are still under review, which, once vetted, will become more new cases. In addition, ICANN Contractual Compliance continues to receive more than 20 new complaints each day. And it is not known how many more complaints are pending with Net 4 India that have not yet been brought to ICANN’s attention.

The termination notice contains 10 pages of complaints from Net4 customers, saying their domains could not be renewed or transferred. Some came from non-profits and hospitals. One registrant said he was contemplating suicide.

Net4’s customer service was non-responsive in each of these cases, the complainants said.

While some of Net4’s problems could be chalked down to coronavirus-related restrictions, the company has been in trouble for much longer.

It entered insolvency proceedings in 2017 after a debt recovery company called Edelweiss bought roughly $28 million of unpaid debt from the State Bank of India and took Net4 to court.

ICANN did not find out about this until April 2019 — it’s probably not a coincidence that this was the same month Net4 was late paying its first ICANN invoice — and it issued its first public breach notice in June that year.

Insolvency is grounds for termination in itself under the Registrar Accreditation Agreement.

It’s never been clearly stated why ICANN did not escalate at that time. Had it done so, it could have saved Net4’s customers from a world of hurt.

The Indian insolvency court admitted last month that it had no jurisdiction over ICANN or the Registrar Accreditation Agreement, both of which are governed primarily by California law.

Nevertheless, the court asked ICANN to not terminate Net4’s contract until after April 25, to give the company time to get its house in order.

But the termination notice, issued on Friday, will see the RAA cut off March 13. ICANN notes that it hasn’t heard from the court-appointed resolution professional, to whom previous breach notices were addressed, since mid-January.

Affected domains — there are still thousands under Net4’s accreditation — will be moved to another registrar under ICANN’s De-Accredited Registrar Transition Procedure.

Net4 could have a say in where its domains wind up. It’s already an OpenProvider reseller so that’s a possibility. Otherwise, ICANN will pick a beneficiary from a queue of qualified candidates.

ICANN throws the book at Net4 over dodgy transfer claims

Struggling Indian registrar Net 4 India has been slammed with a massive breach notice by ICANN, following claims of domain transfers failing or happening without the consent of the registrant.

ICANN also accuses the company, which is or was India’s largest independent registrar, of trying to bullshit its compliance staff about whether expired domains had been renewed or not.

According to ICANN, Net4 is in breach of the Registrar Accreditation Agreement on four counts, three of which relate to domain ownership records.

ICANN says the company isn’t operating a Whois service on the web or port 43, has failed to escrow its registration data on two recent occasions, and has failed to hand over registrant information upon ICANN’s request.

It’s also past due with its fees, ICANN says.

ICANN’s been dealing with complaints about Net4 for months, after the company’s customer service system appeared to break down in the wake of the coronavirus pandemic. Hundreds of customers have said their domains were unrenewable and that they were unable to transfer to another registrar.

In the latest breach notice — the first published breach notice against any registrar since February — ICANN names almost 200 domain names that have allegedly been held hostage at Net4, despite the registrant’s efforts to transfer out.

ICANN wants proof that registrants were given transfer authorization codes and that their domains were unlocked.

In a smaller number of cases, ICANN wants proof that domains were transferred to Net4 partner Openprovider, for which it acts as a reseller, with the consent of the registrants.

It also claims that Net4 has more than once tried to prove that a registrant renewed their expired name by supplying the registry’s expiration date instead of its own, to blag its way out of accusations that registrants were unable to renew.

ICANN also accuses the registrar of dragging its feet to address complaints:

Over the past few months, the number of complaints ICANN Contractual Compliance has received from [registered name holders], and authorized representatives, asserting that Net 4 India is exhibiting a pattern of non-response to domain transfer and renewal requests has steadily increased. While addressing the relevant compliance cases, Net 4 India’s responses to ICANN Contractual Compliance have also regularly been untimely and incomplete.

Net4 is now in the unprecedented position of being subject to two different breach notices simultaneously.

ICANN actually issued a suspension notice in June 2019, after noticing that Net4 had been in insolvency proceedings for two years — a debt recovery agency is trying to recover $28 million in unpaid debts.

But that suspension deadline was paused after talks with the “resolution professional” handling the insolvency case, for reasons ICANN’s been rather quiet about, and it remains on pause to this date.

The newest breach notice has a December 31 deadline on it. Unless Net4 turns on its Whois and hands over the reams of requested data by then, ICANN could terminate its contract.

Assuming the insolvency court allows it to, presumably.

Namecheap accuses GoDaddy of delaying transfers

GoDaddy broke ICANN rules and US competition law by delaying outbound domain transfers yesterday, and not for the first time, according to angry rival Namecheap.
March 6 was Namecheap’s annual Move Your Domain Day, a promotion under which it donates $1.50 to the Electronic Frontier Foundation for every inbound transfer from another registrar.
It’s a tradition the company opportunistically started back in 2011 specifically targeting GoDaddy’s support, later retracted, for the controversial Stop Online Piracy Act, SOPA.
But yesterday GoDaddy was delivering “incomplete Whois information”, which interrupted the automated transfer process and forced Namecheap to resort to manual verification, delaying transfers, Namecheap claims.
“First and foremost this practice is against ICANN rules and regulations. Secondly, we believe it violates ‘unfair competition’ laws,” the company said in a blog post.
Whois verification is a vital part of the transfer process, which is governed by ICANN’s binding Inter-Registrar Transfer Policy.
GoDaddy changed its Whois practices in January. As an anti-spam measure, it no longer publishes contact information, including email addresses vital to the transfer process, when records are accessed automatically over port 43.
However, GoDaddy VP James Bladel told us in January that this was not supposed to affect competing registrars, which have their IP addresses white-listed for port 43 access via a system coordinated by ICANN.
Did GoDaddy balls up its new restrictive Whois practices? Or can the blame be shared?
Namecheap also ran into problems with GoDaddy throttling port 43 on its first Move Your Domain Day in 2011, but DI published screenshots back then suggesting that the company had failed to white-list its IP addresses with ICANN.
This time, the company insists the white-list was not an issue, writing:

As many customers have recently complained of transfer issues, we suspect that GoDaddy is thwarting/throttling efforts to transfer domains away from them. Whether automated or not, this is unacceptable. In preparation for today, we had previously whitelisted IPs with GoDaddy so there would be no excuse for this poor business practice.

Namecheap concluded by saying that all transfers that have been initiated will eventually go through. It also asked affected would-be customers to complain to GoDaddy.
The number of transfers executed on Move Your Domain Day over the last several years appears to be well into six figures, probably amounting to seven figures of annual revenue.

Privacy risk under new domain transfer policy

ICANN’s new domain Transfer Policy, which comes into effect tomorrow, creates risks for users of privacy/proxy services, registrars and others haved warned.
The policy could lead to private registrants having their contact information published in the public Whois for 60 days, the GNSO Council expects to formally tell ICANN this week.
“This could threaten privacy for at-risk registrants without clear benefit,” the Council says in a draft letter to the ICANN board.
The revised Transfer Policy was designed to help prevent domain hijacking.
The main change is that whenever there’s a “change of registrant”, the gaining and losing registrants both have to respond to confirmation emails before the change is processed.
However, “change of registrant” is defined in such a way that the confirmation emails would be triggered even if the registrant has not changed.
For example, if you change your last name in your Whois records due to marriage or divorce, or if you change email addresses, that counts as a change of registrant.
It now turns out that ICANN considers turning a privacy service on or off as a change of registrant, even though that only affects the public Whois data and not the underlying customer data held by the registrar.
The GNSO Council’s draft letter states:

ICANN has advised that any change to the public whois records is considered a change of registrant that is subject to the process defined through IRTP-C. Thus, turning a P/P service on or off is, from ICANN’s view, a change of registrant. It requires the CoR [change of registrant] process to be followed and more importantly could result in a registrant exposing his/her information in the public whois for 60 days. This could threaten privacy for at-risk registrants without clear benefit.

My understanding is that the exposure risk outlined here would only be to registrants who attempt to turn on privacy at their registrar then for whatever reason ignore, do not see or do not understand the subsequent confirmation emails.
Depending on implementation, it could lead to customers paying for a privacy service and not actually receiving privacy.
On the other side of the coin, it’s possible that an actual change in registrant might not trigger the CoR process if both gaining and losing registrants both use the same privacy service and therefore have identical Whois records.
The Council letter also warns about a possible increase in spam due to the changes:

many P/P services regularly generate new email addresses for domains in an effort to reduce spam. This procedure would no longer be possible, and registrants may be subject to unwanted messaging. Implementing the CoR for email changes that some providers do as often as every 3-5 days is not feasible.

ICANN has been aware of these issues for months. Its suggested solution is for registrars to make themselves the “Designated Agent” — a middleman permitted to authorize transfers — for all of their customers.
As we reported earlier this week, many large registrars are already doing this.
But registrars and the GNSO Council want ICANN to consider reinterpreting the new policy to exclude privacy/proxy services until a more formal GNSO policy can be created.
While the Policy Development Process that created the revised transfer rules wound up earlier this year, a separate PDP devoted to creating rules of privacy/proxy services is still active.
The Council suggests that this working group, known as PPSAI, could assume the responsibility of clearing up the mess.
In the meantime, registrars are rather keen that they will not get hit with breach notices by ICANN Compliance for failing to properly implement to what seems to be a complex policy.

Transferring domains gets more complex this week

A new anti-hijacking domain name transfer policy comes into effect this week at all ICANN-accredited registrars, potentially complicating the process of not only selling domains but also updating your own Whois records.
But many registrars have already rewritten their terms of service to make the new rules as hassle-free as possible (and essentially pointless).
From December 1, the old ICANN Inter-Registrar Transfer Policy starts governing inter-registrant transfers too, becoming simply the Transfer Policy.
Now, when you make updates to your Whois records that appear to suggest new ownership, you’ll have to respond to one or two confirmation emails, text messages or phone calls.
The policy change is the latest output of the interminable IRTP work within ICANN’s GNSO, and is designed to help prevent domain hijacking.
But because the changes are likely to be poorly understood by registrants at the outset, it’s possible some friction could be added to domain transfers.
Under the new Transfer Policy, you will have to respond to confirmation emails if you make any of the following:

• A change to the Registered Name Holder’s name or organization that does not appear to be merely a typographical correction;
• Any change to the Registered Name Holder’s name or organization that is accompanied by a change of address or phone number;
• Any change to the Registered Name Holder’s email address.

While registrars have some leeway to define “typographical correction” in their implementation, the notes to the policy seem to envisage single-character transposition and omission errors.
Registrants changing their last names due to marriage or divorce would apparently trigger the confirmation emails, as would transfers between parent and subsidiary companies.
The policy requires both the gaining and losing registrant to verify the “transfer”, so if the registrant hasn’t actually changed they’ll have to respond to two emails to confirm the desired changes.
Making any of the three changes listed above will also cause the unpopular 60-day transfer lock mechanism — which stops people changing registrars — to trigger, unless the registrant has previously opted out.
Registrars are obliged to advise customers that if the change of registrant is a prelude to an inter-registrar transfer, they’d be better off transferring to the new registrar first.
The new policy is not universally popular even among registrars, where complexity can lead to mistakes and therefore support costs.
Fortunately for them, the Transfer Policy introduces the concept of “Designated Agents” — basically middlemen that can approve registrant changes on your behalf.
Some registrars are taking advantage of this exception to basically make the confirmation aspects of the new policy moot.
Calling the confirmation emails an “unnecessary burden”, EuroDNS said last week that it has unilaterally made itself every customer’s Designated Agent by modifying its terms of service.
Many other registrars, including Tucows/OpenSRS, NameCheap and Name.com appear to be doing exactly the same thing.
In other words, many registrants will not see any changes as a result of the new Transfer Policy.
The truism that there’s no domain name policy that cannot be circumvented with a middleman appears to be holding.

Verisign demands 24/7 domain hijacking support

Verisign is causing a bit of a commotion among its registrar channel by demanding 24/7 support for customers whose .com domains have been hijacked.
The changes, we understand, are among a few being introduced into Verisign’s new registry-registrar agreement for .com, which coincides with the renewal of its registry agreement with ICANN.
New text in the RRA states that: “Registrar shall, consistent with ICANN policy, provide to Registered Name Holders emergency contact or 24/7 support information for critical situations such as domain name hijacking.”
From the perspective of registrants, this sounds like a pretty welcome move: who wouldn’t want 24/7 support?
While providing around the clock support might not be a problem for the Go Daddies of the world, some smaller registrars are annoyed.
For a registrar with a small headcount, perhaps servicing a single time zone, 24/7 support would probably mean needing to hire more staff.
Their annoyance has been magnified by the fact that Verisign seems to be asking for these new support commitments without a firm basis in ICANN policy, we hear.
The recently updated transfers policy calls for a 24/7 Transfer Emergency Action Contact — in many cases just a staff member who doesn’t mind being hassled about work at 2am — but that’s meant to be reserved for use by registrars, registries and ICANN.

Go Daddy’s 60-day transfer lock can now be removed

One of Go Daddy’s most unpopular practices – the infamous 60-day domain name transfer lock – has essentially come to an end.
From today, customers will be able to unlock their domains before the period is up, by contacting a special support team, according to director of policy planning James Bladel.
For many years Go Daddy has blocked domains from being transferred to other registrars if changes have been made to the registrant contact information within the last 60 days.
The company alerts users to the lock before they make changes to their Whois data, but that hasn’t stopped the policy bugging the hell out of domainers and regular registrants.
It’s designed to prevent domain hijackings – something Go Daddy says it does very well – but when false positives occur it often looks like a nefarious customer retention strategy.
“It’s a very effective tool for preventing harm, but it does catch out a lot of folks who want to legitimately change registrant data,” Bladel said.
Under the new policy, if Go Daddy blocks a transfer because of the 60-day lock, registrants will be given an email address to contact in order to appeal the block.
According to Bladel, after a human review the locks will be lifted and the Whois data will revert to its original state, unless the Go Daddy support team suspects a hijacking is in progress.
“The bad guys are not going to call and ask us to take a second look at this,” he said. “The bad guys want it to happen under the radar.”
The changes come thanks largely to a new revision of ICANN’s Inter-Registrar Transfer Policy, which came into effect today and specifies that transferring registrants need to be given a way to remove the locks on their domains within five days.
But Bladel said the way the policy is written gave Go Daddy a lot of leeway in how to interpret it – it could have kept the locks in place as before – but it decided to revise its policy to improve the customer experience.

Go Daddy’s 60-day domain lockdown loophole

Perhaps the most common complaint of the many leveled at Go Daddy over the years is that it refuses to allow customers to transfer domains to another registrar for 60 days after an ownership change.
The latest person to fire this criticism at the company is tech blogger Scott Raymond, who published a lengthy tirade against Go Daddy and its policy on ZDNet today.
Raymond points out that Go Daddy seems to be in violation of ICANN’s Inter-Registrar Transfer Policy, which explicitly prohibits the rejection of a transfer request due to a recent Whois change.
He’s not alone. Even Andrew Allemann of Domain Name Wire, hardly Go Daddy’s fiercest critic, said as recently as May that he thinks the company is in violation of the IRTP.
With good reason – this April 2008 ICANN advisory seemed to be specifically written with a ban on Go Daddy’s 60-day policy in mind.
But is the company non-compliant? ICANN doesn’t seem to think so.
I’ve tracked down this November 2009 email from David Giza, then ICANN’s head of compliance, in which he describes what seems to amount to a loophole Go Daddy and other registrars exploit.
Giza explains that the 2008 advisory “only addresses mandatory updates to Whois contact information, not a transfer or assignment to a new registrant”.
Registrants are obliged to keep their Whois data up-to-date; that’s what he means by “mandatory”.
Giza’s email adds:

the transfer policy does not prohibit registrars from requiring registrants to agree to the blocking of transfer requests as a condition for registrar facilitation of optional services such as the transfer of a registration to a new registrant.
We understand GoDaddy.com’s 60-day lock is a voluntary opt-in process where registrants are made aware of and agree to the restriction that the domain name is not to be transferred for 60-days following the completion of transfer. As such, this practice is not prohibited by the transfer policy.

In other words, there are “Whois Changes” and there are “Registrant Changes”, and registrars are only allowed to trigger a lock-down in the latter case, according to Giza.
And according to DNW’s reporting on the subject, that’s exactly what Go Daddy continues to do — locking the domain if certain fields in the registrant record are changed.
So the 60-day lock appears to be kosher, at least in the opinion of ICANN’s erstwhile compliance chief. Whether that could change under the department’s new management is unknown.
As it happens, the subject was raised by a recent working group that was looking into revising the IRTP, but it was so contentious that consensus could not be found.
The problem has been bounced down the road. The most recent mention came in this ICANN issue report (pdf, page 14-15).
Anyway, if I lost you several paragraphs ago, the net result of all this seems to be that Go Daddy probably isn’t breaking the rules, but that nobody can agree whether that’s a good thing or not.
The fact that one has to do this much digging into ICANN esoterica just to figure out whether Go Daddy is screwing its customers over isn’t very reassuring, is it?