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.
Google’s Kenyan web site was reportedly inaccessible yesterday due to a hijacking of the company’s local domain name.
Google.co.ke briefly redirected users to a site bearing the slogan “hacked” on a black background, according to the Daily Nation. A change of DNS was blamed.
Google Kenya reportedly said:
Google services in Kenya were not hacked. For a short period, some users visiting www.google.co.ke and a few other website were re-directed to a different website. We are in contact with the organisation responsible for managing domain names in Kenya.
Google is of course a high-profile target; hackers often exploit weaknesses at third-party providers such as domain name registries in order to take down its satellite sites.
Its Irish site was taken down in October last year, after attackers broke in through a vulnerability in IEDR’s Joomla content management system.
ICANN is to terminate a Russian registrar’s accreditation.
Name For Name Inc, which was given a breach notice last month, is being shut down for basically failing to act as a registrar.
Verisign had already cut off its .com/.net registrar contract and the company was not managing names, providing Whois, or doing any of the other things registrars are supposed to.
Under normal circumstances, a termination sees a mass transfer of all the domains under management to a nominated registrar, but in Name For Name’s case I can’t see that happening.
The company only had five gTLD domain names under management, according to the latest count.
Its accreditation will be terminated September 6.
ICANN also this week issued a breach notice to Visesh Infotecnics (Signdomains.com), apparently as the result of a badly handled domain name hijacking.
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.
ICANN has threatened to terminate Chinese domain name registrar eName Technology after the domain 1111.com was allegedly hijacked.
According to ICANN’s notice of breach (pdf), eName has refused to hand over data documenting the transfer of 1111.com as required by the Registrar Accreditation Agreement.
ICANN claims that when it tried to get eName’s help investigating a hijacking complaint, the company did not return its calls or emails.
The registrar now has 15 days to provide the transfer records as called for by the Inter-Registrar Transfer Policy.
According to historical Whois records, 1111.com was transferred to eName between February 12 and 16 this year. After a complaint, ICANN started chasing eName for the data on February 28.
The domain appears to have been owned by at least four different parties and three different registrars – Network Solutions, then Joker, then eName – since the start of 2012.
It’s the second time that ICANN has sent a breach notice to a registrar over an alleged mishandling of a domain name hijacking, and the first time it’s actually named the domain in question.
In February, the organization threatened Turkish registrar Alantron with the suspension of its contract over the botched handling of pricewire.com.