Latest news of the domain name industry

Recent Posts

Most registrars fail ICANN abuse audit

Kevin Murphy, August 26, 2021, Domain Registrars

The large majority of accredited registrars failed an abuse-related audit at the first pass, according to ICANN.

(UPDATE October 14, 2021: ICANN disagrees with this characterization.)

The audit of 126 registrars, representing over 90% of all registered gTLD domains, founds that 111 were “not fully compliant with the [Registrar Accreditation Agreement’s] requirements related to the receiving and handling of DNS abuse reports”.

Only 15 companies passed with flying colors, ICANN said.

A further 92 have already put in place changes to address the identified concerns, with 19 more still struggling to come into compliance.

The particular parts of the RAA being audited require registrars to publish an abuse email address that it monitored 24/7 and to take action on well-founded cases of abuse within 24 hours of notification.

The results of the audit, carried out by ICANN Compliance and KPMG, can be found here (pdf).

Will you use SSAD for Whois queries?

Kevin Murphy, July 9, 2021, Domain Policy

ICANN is pinging the community for feedback on proposed Whois reforms that would change how people request access to private registrant data.

The fundamental question is: given everything you know about the proposed System for Standardized Access and Disclosure (SSAD), how likely are you to actually use it?

The SSAD idea was dreamed up by a community working group as the key component of ICANN’s response to privacy laws such as GDPR, and was then approved by the Generic Names Supporting Organization.

But it’s been criticized for not going far enough to grant Whois access to the likes of trademark lawyers, law enforcement and security researchers. Some have called it a glorified ticketing system that will cost far more than the value it provides.

Before the policy is approved by ICANN’s board, it’s going through a new procedure called the ODP, for Operational Design Phase, in which ICANN staff, in coordination with the community, attempt to figure out whether SSAD would be cost-effective, or even implementable.

The questionnaire released today will be an input to the ODP. ICANN says it “will play a critical role in assessing the feasibility and associated risks, costs, and resources required in the potential deployment of SSAD.”

There’s only eight questions, and they mostly relate to the volume of private data requests submitted currently, how often SSAD is expected to be used, and what the barriers to use would be.

ICANN said it’s asking similar questions of registries and registrars directly.

There’s a clear incentive here for the IP and security factions within ICANN to low-ball the amount of usage they reckon SSAD will get, whether that’s their true belief or not, if they want ICANN to strangle the system in its crib.

It’s perhaps noteworthy that the potential user groups the questionnaire identifies do not include domain investors nor the media, both of which have perfectly non-nefarious reasons for wanting greater access to Whois data. This is likely because these communities were not represented on the SSAD working group.

You can find the questionnaire over here. You have until July 22.

ICANN name servers come under attack

Kevin Murphy, April 30, 2021, Domain Tech

ICANN’s primary name servers came under a distributed denial of service attack, the Org said earlier this week.

The incident appears to have gone largely unnoticed outside of ICANN and seems to have been successfully mitigated before causing any significant damage.

ICANN said on its web site:

ICANN was subjected to a Distributed Denial of Service (DDoS) attack targeting NS.ICANN.ORG. This event did not result in harm to the organization. It was mitigated by redirecting traffic flows through a DDoS scrubbing service.

ns.icann.org is the address of ICANN’s name servers, which handle queries to ICANN-owned domains such as icann.org and iana.org.

The servers are also authoritative for Ugandan ccTLD .ug for some reason, and until a few years ago also handled the .int special-purpose TLD and sponsored gTLD .museum.

ICANN did not disclosed the exact date of the attack, nor speculate about whether it was targeted and why it might have happened.

DNS genius and ICANN key-holder Dan Kaminsky dies at 42

Kevin Murphy, April 27, 2021, Domain Tech

Security researcher Dan Kaminsky, best known for uncovering the so-called “Kaminsky Bug” DNS vulnerability, has reportedly died at the age of 42.

It has been widely reported that Kaminsky’s niece confirmed his death from serious complications from his longstanding diabetes.

On Twitter, she rebutted emerging conspiracy theories that his death was linked to the coronavirus vaccine, which he had received April 12, saying her uncle would “laugh” at such views.

During his career as a white-hat hacker, Kaminsky worked for companies including Cisco, Avaya, and IOActive.

He occasionally spoke at ICANN meetings on security issues, and was since 2010 one of IANA’s seven Recovery Key Share Holders, individuals trusted to hold part of a cryptographic key that would be used to reboot root zone DNSSEC in the case of a massive disaster.

But he was best known for his 2008 discovery of a fundamental flaw in the DNS protocol that allowed cache poisoning, and therefore serious man-in-the middle attacks, across millions of name servers worldwide. He worked with DNS software vendors in private to help them with their patches before the problem was publicly disclosed.

His discoveries led in part to the ongoing push for DNSSEC deployment across the internet.

The vulnerability received widespread attention, even in the mainstream media, and quickly came to bear his name.

For me, my standout memory of Kaminsky is one of his series of annual “Black Ops” talks, at the Defcon 12 conference in Las Vegas in 2004, during which he demonstrated to a rapt audience of hackers how it was possible to stream live radio by caching small chunks of audio data in the TXT fields of DNS records and using DNS queries to quickly retrieve and play them in sequence.

As well as being a bit of a DNS genius, he knew how to work a stage: the crowd went mental and I grabbed him for an interview soon after his talk was over.

His death at such a young age is a big loss for the security community.

IP lobby demands halt to Whois reform

Kevin Murphy, March 17, 2021, Domain Policy

Trademark interests in the ICANN community have called on the Org to freeze implementation of the latest Whois access policy proposals, saying it’s “not yet fit for purpose”.

The Intellectual Property Constituency’s president, Heather Forrest, has written (pdf) to ICANN chair Maarten Botterman to ask that the so-called SSAD system (for Standardized System for Access and Disclosure) be put on hold.

SSAD gives interested parties such as brands a standardized pathway to get access to private Whois data, which has been redacted by registries and registrars since the EU’s Generic Data Protection Regulation came into force in 2018.

But the proposed policy, approved by the GNSO Council last September, still leaves a great deal of discretion to contracted parties when it comes to disclosure requests, falling short of the IPC’s demands for a Whois that looks a lot more like the automated pre-GDPR system.

Registries and registrars argue that they have to manually verify disclosure requests, or risk liability — and huge fines — under GDPR.

The IPC has a few reasons why it reckons ICANN should slam the brakes on SSAD before implementation begins.

First, it says the recommendations sent to the GNSO Council lacked the consensus of the working group that created them.

Intellectual property, law enforcement and security interests — the likely end users of SSAD — did not agree with big, important chucks of the working group’s report. The IPC reckons eight of the 18 recommendations lacked a sufficient degree of consensus.

Second, the IPC claims that SSAD is not in the public interest. If the entities responsible for “policing the DNS” don’t think they will use SSAD due to its limitations, then why spend millions of ICANN’s money to implement it?

Third, Forrest writes that emerging legislation out of the EU — the so-called NIS2, a draft of a revised information security directive —- puts a greater emphasis on Whois accuracy

Forrest concludes:

We respectfully request and advise that the Board and ICANN Org pause any further work relating to the SSAD recommendations in light of NIS2 and given their lack of community consensus and furtherance of the global public interest. In light of these issues, the Board should remand the SSAD recommendations to the GNSO Council for the development of modified SSAD recommendations that meet the needs of users, with the aim of integrating further EU guidance.

It seems the SSAD proposals will be getting more formal scrutiny than previous GNSO outputs.

When the GNSO Council approved the recommendations in September, it did so with a footnote asking ICANN to figure out whether it would be cost-effective to implement an expensive — $9 million to build, $9 million a year to run — system that may wind up being lightly used.

ICANN has now confirmed that SSAD and the other Whois policy recommendations will be one of the first recipients of the Operational Design Phase (pdf) treatment.

The ODP is a new, additional layer of red tape in the ICANN policy-making sausage machine that slots in between GNSO Council approval and ICANN board consideration, in which the Org, in collaboration with the community, tries to figure out how complex GNSO recommendations could be implemented and what it would cost.

ICANN said this week that the SSAD/Whois recommendations will be subject to a formal ODP in “the coming months”.

Any question about the feasibility of SSAD would be referred back to the GNSO, because ICANN Org is technically not supposed to make policy.

Amid .club boom, one AV vendor is blocking the whole damn TLD

Kevin Murphy, January 27, 2021, Domain Registries

.club may be experiencing a mini-boom in sales due to the popular new Clubhouse app, but one antivirus vendor has reportedly decided to block the entire TLD.

According to Forbes, the free MalwareBytes Browser Guard plug-in will warn users attempting to visit .club sites that it’s a “suspicious top-level domain”, adding that .club is “frequently used by scam or phishing sites, but can be used by legitimate websites as well”.

Users can click through to dismiss the warning and visit the site if they choose.

It seems a lot like overkill or an algorithmic glitch to me — .club has never been a particularly malware-friendly TLD. According to SpamHaus, only 0.9% of the .club domains that it’s seen in the wild could be considered “bad”.

After a disappointing second half of 2020, which saw about 300,000 domains disappear from its zone file, .club has seen a bit of a recovery in the last two weeks, largely due to a popular new audio social media app called Clubhouse.

Since the app started getting media attention earlier this month, .club has become the latest TLD hit by domain investor speculation with .CLUB Domains CEO Colin Campbell describing sales on January 15 as “absolute pandemonium”.

While .club has added about 30,000 domains to its zone since then, it’s not yet enough to counteract last year’s decline in volume. Luckily for .CLUB, many of its sales have been of premium-priced names.

It’s unlikely that these latest registrations are related to the MalwareBytes block.

ICANN apologizes to “arms dealer” claim security firm after email goes missing

Kevin Murphy, August 31, 2020, Domain Registrars

ICANN has apologized to the security company that claimed an accredited registrar was in league with malware distributors, after an email went AWOL.

You may recall that registrar GalComm was accused by Awake Security last month of turning a blind eye to abuse in a report entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars” and that ICANN’s preliminary investigation later essentially dismissed the allegations.

ICANN had told GalComm (pdf) August 18 that Awake had not “to date” contacted ICANN about its allegations, but that appears to have been untrue.

GalComm’s lawyers had in fact emailed a letter to ICANN, using its “globalsupport” at icann.org email address, on August 6, as said lawyers testily informed (pdf) Global Domains Division VP Russ Weinstein August 20.

Weinstein has now confirmed (pdf) that a letter from Awake was received to said email address but “was not escalated internally”. He said he was “previously unaware” of the letter. He wrote:

I apologize for this inadvertent oversight and we will use this as a training opportunity to prevent such errors in the future.

GalComm has been threatening to sue Awake for defamation since the “arms dealer” report was published, so it looks like ICANN’s decision to eat humble pie is probably a prudent way to keep its name off the docket.

The letter from Awake’s lawyers (pdf) also includes a lengthy explanation of why the original report is not, in its view, defamatory.

The lesson for the rest of us appears to be that the ICANN email address in question is probably not the best way to reach ICANN’s senior management.

Weinstein said that abuse complaints about registrars should be sent to its “compliance” at icann.org address.

“Arms dealer” registrar probed by ICANN

Kevin Murphy, August 20, 2020, Domain Registrars

ICANN’s top security thinkers are looking into hotly denied claims that an Israeli registrar collaborated with malware distributors.

Luckily for the registrar, GalComm, so far they’ve come up empty-handed and ICANN has told the company it does not consider it “malicious”.

ICANN told GalComm this week that its Security, Stability and Resiliency team is looking into a report published by security consultancy Awake Security in June entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars”.

The report connected GalComm to over 100 malicious browser extensions, used to steal data, that have been installed 33 million times. GalComm was apparently the attackers’ registrar of choice.

While Awake did not report the registrar to ICANN, GalComm took it upon itself to write to ICANN to deny the allegations, saying that it merely acted as a neutral registrar and had no involvement in hosting or distributing the malware.

It also demanded that Awake retract its report and apologize or face legal consequences. The report is still available.

Now, ICANN has written back (pdf) to assure the registrar that its investigations to date has been “unable to corroborate the findings Awake Security presented and it does appear that Awake Security had an inaccurate picture of the total domains under management by GalComm”.

It added that the investigation is ongoing, however:

Based on the information we have been able to obtain to date, we have no reason to believe it appropriate for GalComm to be considered a “malicious domain registrar” as asserted by Awake Security. However, as noted in Awake Security’s report, the malicious actors behind the domains in question may be utilizing detection evasion techniques. As such, our investigations continue, and we appreciate GalComm’s cooperation and support of those investigations.

ICANN has previously told news outlets that it receives very few complaints about GalComm, none related to malware.

“Horrifying” Zoombombing attack on ICANN meeting, again

Kevin Murphy, June 22, 2020, Domain Policy

ICANN’s eleventh-hour decision to remove password requirements for ICANN 68 was proved wrong almost immediately after the meeting got underway on Zoom today.

According to participants and ICANN itself, several sessions were “zoombombed” this morning, with apparently pornographic content.

Zoombombing is where trolls disrupt public, open Zoom meetings with content designed to offend.

ICANN 68 is taking place on Zoom, but on Kuala Lumpur time. I was asleep during the attacks and ICANN has yet to post the recordings of any of today’s sessions, so I can’t give you any of the details first-hand.

But judging by a handful of social media posts that reference the attack, it seems to have been pornographic in nature. ICANN said it comprised “audio, images and video”.

One participant described it as “funny at first…until it was not”, while another said it was “horrifying” and left her feeling “completely vulnerable”.

ICANN said in a blog post that the trolls were swiftly removed from the sessions.

It added that it has changed the format of the remainder of ICANN 68, unplugging certain interactive components and requiring passwords to be entered before access is granted.

This means you’re going to have to register for each session and click emailed confirmation links, it appears.

Only the Governmental Advisory Committee is staying on the platform with its original vulnerable configuration.

ICANN had been planning to require passwords since a similar attack at an inter-sessional meeting in March, but changed its mind last week after security upgrades made by Zoom gave leaders a greater sense of confidence in the platform.

It appears that confidence was misplaced.

You won’t need a password for ICANN 68 after all

Kevin Murphy, June 17, 2020, Domain Policy

ICANN has ditched plans to require all ICANN 68 participants to enter a password whenever they enter one of the Zoom sessions at the meeting next week.

The org said today that it will use URLs with embedded passwords, removing the need for user input, after reviewing changes Zoom made last month.

These included features such as a waiting room that enables meeting hosts to vet participants manually before allowing them to enter the meeting proper.

ICANN said: “Please use these links cautiously, only share them on secure channels such as encrypted chat or encrypted e-mail, and never post them publicly.”

ICANN had said last month, before the Zoom changes, that it would require passwords in order to limit the risk of Zoombombing — where trolls show up and spam the meeting with offensive content. One ICANN Zoom session had been trolled in this way in March.

The org also said today that participants will be asked to give their consent to be recorded upon entry to a session.

“It is our hope that this small change empowers attendees by providing quick access and more control over the acceptance of our policies as it relates to attending virtual meetings,” ICANN lied, to cover for the obvious piece of legal ass-covering.

Refuse consent and see how far you get.