Latest news of the domain name industry

Recent Posts

Web.com got pwned

Kevin Murphy, November 4, 2019, Domain Registrars

Web.com, which owns top 20 registrars Network Solutions and Register.com, got itself and millions of its customers hacked a few months ago.

The company disclosed last week that malicious hackers broke into its network in late August, making off with customer account information.

The attack was not discovered until October 16.

The compromised data included “name, address, phone numbers, email address and information about the services that we offer to a given account holder”, Web.com said.

“We encrypt credit card numbers and no credit card data was compromised as a result of this incident,” it added.

Customers are being told to change their password next time they log in to their services.

It’s not clear how many registrants were affected. The NetSol accreditation has over seven million domains in the gTLDs alone, while Register.com has almost 1.8 million.

Web.com said it brought on a private security firm to investigate the attack, and informed US law enforcement.

Emoji domains get a 😟 after broad study

Kevin Murphy, October 28, 2019, Domain Tech

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.

The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.

The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.

It’s 30 pages long, and you can read it here (pdf).

Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.

But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.

That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.

Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.

The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:

Emoji comparison

If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.

There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.

In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.

Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.

Spam is not our problem, major domain firms say ahead of ICANN 66

Kevin Murphy, October 21, 2019, Domain Policy

Eleven of the largest domain name registries and registrars have denied that spam is something they should have to deal with, unless it’s used to proliferate other types of abuse such as phishing or malware.

In a newly published “Framework to Address Abuse” (pdf), the companies attempt to define the term “DNS abuse” narrowly to capture only five (arguably only four and a half) specific types of online threat.

That abuse comprises malware, phishing, botnets, pharming and spam.

The companies agree that these are activities which registrars and registries “must” act upon.

But the document notes that not all spam is its responsibility, stating:

While Spam alone is not DNS Abuse, we include it in the five key forms of DNS Abuse when it is used as a delivery mechanism for the other four forms of DNS Abuse. In other words, generic unsolicited e-mail alone does not constitute DNS Abuse, but it would constitute DNS Abuse if that e-mail is part of a phishing scheme.

In other words, registrars and registries should not feel responsible for the billions of spams sent every day using their domains, unless the spam runs further malware, phishing, pharming or botnet abuse.

The signatories of the framework are Public Interest Registry, GoDaddy, Donuts, Tucows, Amazon Registry Services, Blacknight, Afilias, Name.com, Amazon Registrar, Neustar, and Nominet UK.

It may seem like they’ve presented a surprisingly narrow definition, but it’s in line with what current ICANN contracts dictate.

Neither the standard Registry Agreement nor Registrar Accreditation Agreement mention spam at all. Six years ago, ICANN specifically said that spam is “outside of ICANN’s scope and authority”.

Under the RA, registries have to oblige their registrars to ban registrants from “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law”.

They also have to maintain statistical reports on the amount of “pharming, phishing, malware, and botnets” in their zones, and provide those reports to ICANN upon demand. A recent audit found that 5% of registries, mainly dot-brands, were not doing this.

However, ICANN’s Domain Abuse Activity Reporting system, an effort to provide some transparency into how gTLDs are being abused, does in fact track spam. It does not track pharming, which is a fairly obscure and little-used form of DNS attack.

The DAAR report for September shows that spam constituted 73% of all tracked abuse.

The ICANN board of directors today identified DAAR as one of a few dozen priorities for the coming year.

Similarly, the cross-community working group known as the CCT Review Team, which was tasked with looking into how the new gTLD program has impacted competition and consumer trust, had harsh words for spam-friendly registries, and provided a definition of “DNS Security Abuse” that specifically included “high volume spam”.

The review recommended that ICANN introduce more measures to force contracted parties to deal with this type of abuse. This could include incentives for registries to clean up their zones and abuse volume thresholds that would automatically trigger compliance actions.

The new framework document comes in the context of an ongoing debate within the ICANN community about what “DNS abuse” is.

Two partners at Interisle, a security consultancy that often works for ICANN, recently guest-posted on DI to say that this term has become meaningless and should be abandoned in favor of “security threat”.

They argued that the definition should include not only spam, but also stuff like IP infringement, election interference, and terrorism.

But the main threat to contracted parties probably comes from the Governmental Advisory Committee, backed by law enforcement, which is pushing for stronger rules covering abusive content.

During a webinar last week, the US Federal Trade Commission, the FBI, and Europol argued that registries and registrars should be obliged to do more to combat abuse, specifically including spam.

“Whether or not you call it phishing or spam or whether it has a malware payload or not, ultimately it’s all email, and email remains the most common tool of cybercriminals to ensnare their victims, and that’s why we in law enforcement care about the domains used to send emails,” said Gabriel Andrews of the FBI’s Cyber Initiative Resource Fusion Unit, on the call.

Registries and registrars countered, using the same language found in the new framework, that generic spam is a content issue, and outside of their remit.

The two sides are set to clash again at ICANN’s annual general meeting in Montreal next month, in a November 6 face-to-face session.

While 11 entities signed the new framework, it’s arguably only nine companies. Name.com is owned by Donuts and both Amazon firms obviously have the same parent.

But it does include the two largest registrars, and registries responsible for running several hundred commercial gTLDs, dot-brands and ccTLDs.

While none of the signatories of the framework have a particular reputation for being spam-friendly, other companies in the industry — particularly some of the newest and cheapest new gTLDs — tend to attract spammers like flies to a turd.

Some of the signatories are perhaps surprising, given their past or ongoing behavior to tackle content-based abuse in their own zones.

Nominet, notably, takes down tens of thousands of domains ever year based on little more than police assurances that the domains are being used to sell counterfeit merchandise or infringe copyright.

The .uk registry also preemptively suspends domains based on algorithms that guess whether they’re likely to be seen as encouraging sexual violence or could be used in phishing attacks.

Donuts also has a trusted notifier relationship with the movie and music industries that has seen it take down dozens of names being used for mass copyright infringement.

PIR has previous endorsed, then unendorsed, the principal of a “UDRP for copyright”, a method of giving Big Content a way of going through due process to have domains taken or suspended.

Outside the spam issue, while the new registry-registrar framework says that registries and registrars should not get involved in matters related to web site content, it also says they nevertheless “should” (as opposed, one assumes based on the jargon usually found in internet standards, to “must”) suspend domains when they’re being used to distribute:

(1) child sexual abuse materials (“CSAM”); (2) illegal distribution of opioids online; (3) human trafficking; and (4) specific and credible incitements to violence.

These are exceptions because they constitute “the physical and often irreversible threat to human life”, the framework says.

Ultimately, this all boils down to a religious debate about where the line is drawn between “DNS” and “content”, it seems to me.

The contracted parties draw the line at threats to human life, whereas others want action on other forms of abuse largely because registries and registrars are in the best position to help.

Crunch time, again, for Whois access policy

Kevin Murphy, October 14, 2019, Domain Policy

Talks seeking to craft a new policy for allowing access to private Whois data have hit another nodal point, with the community now pressuring the ICANN board of directors for action.

The Whois working group has more or less decided that a centralized model for data access, with ICANN perhaps acting as a clearinghouse, is the best way forward, but it needs to know whether ICANN is prepared to take on this role and all the potential liabilities that come with it.

Acronym time! The group is known as the Whois EPDP WG (for Expedited Policy Development Process Working Group) and it’s come up with a rough Whois access framework it’s decided to call the Standardized System for Access and Disclosure (SSAD).

Its goal is to figure out a way to minimize the harms that Europe’s General Data Protection Regulation allegedly caused to law enforcement, IP owners, security researchers and others by hiding basically all gTLD registration data by default.

The SSAD, which is intended to be as automated as possible, is the working group’s proposed way of handling this.

The “hamburger model” the EPDP has come up with sees registries/registrars and data requestors as the top and bottom of the sandwich (or vice versa) with some yet-to-be-decided organizational patty filling acting as an interface between the two.

The patty would handle access control for the data requests and be responsible for credentialing requestors. It could either be ICANN acting alone, or ICANN coordinating several different interface bodies (the likes of WIPO have been suggested).

Should the burger be made only of mashed-up cow eyelids, or should it incorporate the eyelids of other species too? That’s now the question that ICANN’s board is essentially being posed.

Since this “phase two” work kicked off, it’s taken about five months, 24 two-hour teleconferences, and a three-day face-to-face meeting to get to this still pretty raw, uncooked state.

The problem the working group is facing now is that everyone wants ICANN to play a hands-on role in running a centralized SSAD system, but it has little idea just how much ICANN is prepared to get involved.

The cost of running such a system aside, legislation such as GDPR allows for pretty hefty fines in cases of privacy breaches, so there’s potentially a big liability ask of notoriously risk-averse ICANN.

So the WG has written to ICANN’s board of directors in an attempt to get a firm answer one way or the other.

If the board decided ICANN should steer clear, the WG may have to go back more or less to square one and focus on adapting the current Whois model, which is distributed among registrars and registries, for the post-GDPR world.

How much risk and responsibility ICANN is willing to absorb could also dictate which specific SSAD models the WG pursues in future.

There’s also a view that, with no clarity from ICANN, the chance of the WG reaching consensus is unlikely.

This will be a hot topic at ICANN 66 in Montreal next month.

Expect the Governmental Advisory Committee, which had asked for “considerable and demonstrable progress, if not completion” of the access model by Montreal, to be disappointed.

Sixty gTLD registries not monitoring security threats

Kevin Murphy, September 18, 2019, Domain Registries

Roughly 5% of gTLD registry operators have been doing no abuse monitoring, despite contractual requirements to do so, a recent ICANN audit has found.

ICANN checked with 1,207 registries — basically all gTLDs — between November 2018 and June, and found about 60 of them “were not performing any security threat monitoring, despite having domains registered in their gTLDs”.

A further 180 (15%) were not doing security checks, but had no registered domains, usually because they were unused dot-brands. ICANN told these companies that they had to do the checks anyway, to remain in compliance.

In all cases, ICANN said, the registries remediated their oversights during the audit to bring their gTLDs back into compliance.

ICANN does not name the non-compliant registries in the summary of the audit’s results, published yesterday (pdf).

Registries under the 2012 new gTLD base registry agreement all have to agree to this:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

It’s possible to keep tabs on abuse by monitoring domain blocklists such as SpamHaus, SURBL and PhishTank. Some such lists are freely available, others carry hefty licensing fees.

ICANN itself monitors these lists through its Domain Abuse Activity Reporting project, so it’s able to work out the differences between the levels of abuse registries report and what the empirical data suggests.

Registries typically either use these lists via in-house tools or license products provided by vendors such as Neustar, RegistryOffice, Knipp, CSC, DOTZON, Afnic, AusCERT, Shadowserver, Telefonica, Secure Domain Foundation and Netcraft, ICANN said.

Perhaps unsurprisingly, there’s a bit of disagreement between ICANN and some registries about how the somewhat vague obligations quote above are be interpreted.

ICANN thinks registries should have to provide information about specific domains that were identified as abusive and what remediation actions were taken, but some registries think they only have to provide aggregate statistical data (which would be my read of the language).

The contracts also don’t specify how frequently registries much carry out security reviews.

Of the 80% (965) of registries already in compliance, 80% (772) were doing daily abuse monitoring. Others were doing it weekly, monthly, or even quarterly, ICANN found, all of which appear to be in line with contractual requirements.

ICANN must do more to fight internet security threats [Guest Post]

ICANN and its contracted parties need to do more to tackle security threats, write Dave Piscitello and Lyman Chapin of Interisle Consulting.

The ICANN Registry and Registrar constituencies insist that ICANN’s role with respect to DNS abuse is limited by its Mission “to ensure the stable and secure operation of the internet’s unique identifier systems”, therefore limiting ICANN’s remit to abuse of the identifier systems themselves, and specifically excluding from the remit any harms that arise from the content to which the identifiers point.

In their view, if the harm arises not from the identifier, but from the thing identified, it is outside of ICANN’s remit.

This convenient formulation relieves ICANN and its constituencies of responsibility for the way in which identifiers are used to inflict harm on internet users. However convenient it may be, it is fundamentally wrong.

ICANN’s obligation to operate “for the benefit of the Internet community as a whole” (see Bylaws, “Commitments”) demands that its remit extend broadly to how a domain name (or other Internet identifier) is misused to point to or lure a user or application to content that is harmful, or to host content that is harmful.

Harmful content itself is not ICANN’s concern; the way in which internet identifiers are used to weaponize harmful content most certainly is.

Rather than confront these obligations, however, ICANN is conducting a distracting debate about the kinds of events that should be described as “DNS abuse”. This is tedious and pointless; the persistent overloading of the term “abuse” has rendered it meaningless, ensuring that any attempt to reach consensus on a definition will fail.

ICANN should stop using the term “DNS abuse” and instead use the term “security threat”.

The ICANN Domain Abuse Activity Reporting project and the Governmental Advisory Committee (GAC) use this term, which is also a term of reference for new TLD program obligations (Spec 11) and related reporting activities. It is also widely used in the operational and cybersecurity communities.

Most importantly, the GAC and the DAAR project currently identify and seek to measure an initial set of security threats that are a subset of a larger set of threats that are recognized as criminal acts in jurisdictions in which a majority of domain names are registered.

ICANN should acknowledge the GAC’s reassertion in its Hyderabad Communique that the set of security threats identified in its Beijing correspondence to the ICANN Board were not an exhaustive list but merely examples. The GAC smartly recognized that the threat landscape is constantly evolving.

ICANN should not attempt to artificially narrow the scope of the term “security threat” by crafting its own definition.

It should instead make use of an existing internationally recognized criminal justice treaty. The Council of Europe’s Convention on Cybercrime is a criminal justice treaty that ICANN could use as a reference for identifying security threats that the Treaty recognizes as criminal acts.

The Convention is recognized by countries in which a sufficiently large percentage domain names are registered that it can serve the community and Internet users more effectively and fairly than any definition that ICANN might concoct.

ICANN should also acknowledge that the set of threats that fall within its remit must include all security events (“realized security threats”) in which a domain name is used during the execution of an attack for purposes of deception, for infringement on copyrights, for attacks that threaten democracies, or for operation of criminal infrastructures that are operated for the purpose of launching attacks or facilitating criminal (often felony) acts.

What is that remit?

ICANN policy and contracts must ensure that contracted parties (registrars and registries) collaborate with public and private sector authorities to disrupt or mitigate:

  • illegal interception or computer-related forgery,
  • attacks against computer systems or devices,
  • illegal access, data interference, or system interference,
  • infringement of intellectual property and related rights,
  • violation of laws to ensure fair and free elections or undermine democracies, and
  • child abuse and human trafficking.

We note that the Convention on Cybercrime identifies or provides Guidance Notes for these most prevalently executed attacks or criminal acts:

  • Spam,
  • Fraud. The forms of fraud that use domain names in criminal messaging include, business email compromise, advance fee fraud, phishing or other identity thefts.
  • Botnet operation,
  • DDoS Attacks: in particular, redirection and amplification attacks that exploit the DNS
  • Identity theft and phishing in relation to fraud,
  • Attacks against critical infrastructures,
  • Malware,
  • Terrorism, and,
  • Election interference.

In all these cases, the misuse of internet identifiers to pursue the attack or criminal activity is squarely within ICANN’s remit.

Registries or registrars should be contractually obliged to take actions that are necessary to mitigate these misuses, including suspension of name resolution, termination of domain name registrations, “unfiltered and unmasked” reporting of security threat activity for both registries and registrars, and publication or disclosure of information that is relevant to mitigating misuses or disrupting cyberattacks.

No one is asking ICANN to be the Internet Police.

The “ask” is to create policy and contractual obligations to ensure that registries and registrars collaborate in a timely and uniform manner. Simply put, the “ask” is to oblige all of the parties to play on the same team and to adhere to the same rules.

This is unachievable in the current self-regulating environment, in which a relatively small number of outlier registries and registrars are the persistent loci of extraordinary percentages of domain names associated with cyberattacks or cybercrimes and the current contracts offer no provisions to suspend or terminate their operations.

This is a guest editorial written by Dave Piscitello and Lyman Chapin, of security consultancy Interisle Consulting Group. Interisle has been an occasional ICANN security contractor, and Piscitello until last year was employed as vice president of security and ICT coordination on ICANN staff. The views expressed in this piece do not necessary reflect DI’s own.

ICANN’s new conferencing software has a webcam security bug

Kevin Murphy, July 10, 2019, Domain Tech

ICANN can’t catch a break when it comes to remote participation security, it seems.

Having just recently made the community-wide switch away from Adobe Connect to Zoom, partly for security reasons, now Zoom has been hit by what many consider to be a critical zero-day vulnerability.

Zoom (which, irrelevantly, uses a .us domain) pushed out an emergency patch for the vulnerability yesterday, which would have allowed malicious web sites to automatically turn on visitors’ webcams without their consent.

Only users of the installable Mac client were affected.

According to security researcher Jonathan Leitschuh, who discovered the problem, Zoom’s Mac client was installing a web server on users’ machines in order to bypass an Apple security feature that requires a confirmatory click before the webcam turns on.

This meant a web site owner could trick a user into a Zoom session, with their camera turned on by default, without their knowledge or consent.

If you’re in the habit of keeping your webcam lens uncovered, that’s potentially a big privacy problem, especially if you do most of your remote coverage of ICANN meetings from the toilet.

It appears that Leitschuh, who reported the problem to Zoom three months ago, took issue with what he saw as the company’s ambivalent attitude to fixing it in a timely fashion.

When he finally blogged about it on Monday, after giving Zoom a 90-day “responsible disclosure” period to issue a patch, the problem still hadn’t been fully resolved, he wrote.

But, following media coverage, Zoom’s new patch apparently removes the covert web server completely. This removes the vulnerability but means Apple users will have to click a confirmation button before joining Zoom meetings in future.

Zoom is used now for all of ICANN’s remote participation, from sessions of its public meetings to discussions of its policy-making working groups.

I really like it. It feels a lot less clunky than Adobe, and it’s got some nifty extra features such as the ability to skip around in recordings based on an often-hilarious machine-transcription sidebar, which makes my life much easier.

One of the reasons ICANN made the switch was due to a bug found in Adobe Connect last year that could have been used to steal confidential information from closed meetings.

ICANN actually turned off Adobe Rooms for remote participants halfway through its public meeting in Puerto Rico due to the bug.

The switch to Zoom was hoped to save ICANN $100,000 a year.

Airline hit with $230 million GDPR fine

Kevin Murphy, July 8, 2019, Domain Policy

British Airways is to be fined £183.39 million ($230 million) over a customer data breach last year, by far the biggest penalty to be handed out under the General Data Protection Regulation to date.

This story is not directly related to the domain name industry, but it does demonstrate that European data protection authorities are not messing about when it comes to GDPR enforcement.

About 500,000 BA customers had their personal data — including full payment card details — stolen by attackers between June and September last year, the UK Information Commissioner’s Office said today..

It is believed that they obtained the data not by hacking BA’s database, but rather by inserting a script hosted by third-party domain that executed whenever a customer transacted with the site, allowing credentials to be captured in real time.

The ICO said its decision to fine $183.39 million — which amounts to more than 1.5% of BA’s annual revenue — is preliminary and can be appealed by BA.

Under GDPR, which came into effect in May 2018, companies can be fined up to 4% of revenue.

The biggest pre-GDPR fine is reportedly the £500,000 penalty that Facebook was given due to the Cambridge Analytica scandal.

GDPR is of course of concern to the domain industry due to the ongoing attempts to make sure Whois databases are compliant with the laws.

PwC wants to be your Whois gatekeeper

Kevin Murphy, June 11, 2019, Domain Services

PricewaterhouseCoopers has built a Whois access system that may help domain name companies and intellectual property interests call a truce in their ongoing battle over access to private Whois data.

Its new TieredAccess Platform will enable registries and registrars to “outsource the entire process of providing access to non-public domain registration data”.

That’s according to IP lawyer Bart Lieben, partner at the Belgian law firm ARTES, who devised the system and is working with PwC to develop it.

The offering is designed to give trademark lawyers access to the data they lust after, while also reducing costs and mitigating domain name industry liability under the General Data Protection Regulation.

TieredAccess would make PwC essentially the gatekeeper for all requests for private Whois data (at least, in the registries plugged into the platform) coming from the likes of trademark owners, security researchers, lawyers and law enforcement agencies.

At one end, these requestors would be pre-vetted by PwC, after which they’d be able to ask for unredacted Whois records using PwC as an intermediary.

They’d have to pick from one of 43 pre-written request scenarios (such as cybersquatting investigation, criminal probe or spam prevention) and assert that they will only use the data they obtain for the stated purposes.

At the other end, registries and registrars will have adopted a set of rules that specify how such requests should be responded to.

A ruleset could say that cops get more access to data than security researchers, for example, or that a criminal investigation is more important than a UDRP complaint.

PwC has created a bunch of templates, but registrars and registries would be able to adapt these policies to their own tastes.

Once the rules are put in place, and the up-front implementation work has been done to plug PwC into their Whois servers, they wouldn’t have to worry about dealing with Whois requests manually as most are today. The whole lot would be automated.

Not even PwC would have human eyes on the requests. The private data would only be stored temporarily.

One could argue that there’s the potential for abusive or non-compliant requests making it through, which may give liability-nervous companies pause.

But the requests and response metadata would be logged for audit and compliance, so abusive users could be fingered after the act.

Lieben says the whole system has been checked for GDPR compliance, assuming its prefabricated baseline scenarios and templates are adopted unadulterated.

He said that the PwC brand should give clients on both sides “peace of mind” that they’re not breaking privacy law.

If a registrar requires an affidavit before releasing data, the assertions requestors make to PwC should tick that box, he said.

Given that this is probably a harder sell to the domain name industry side of the equation, it’s perhaps not surprising that it’s the requestors that are likely to shoulder most of the cost burden of using the service.

Lieben said a pricing model has not yet been set, but that it could see fees paid by registrars subsidized by the fees paid by requestors.

There’s a chance registries could wind up paying nothing, he said.

The project has been in the works since September and is currently in the testing phase, with PwC trying to entice registries and registrars onto the platform.

Lieben said some companies have already agreed to test the service, but he could not name them yet.

The service was developed against the backdrop of ongoing community discussions within ICANN in the Expedited Policy Development Working group, which is trying to create a GDPR-compliant policy for access to private Whois records.

ICANN Org has also made it known that it is considering making itself the clearinghouse for Whois queries, to allow its contracted parties to offload some liability.

It’s quite possible that once the policies are in place, ICANN may well decide to outsource the gatekeeper function to the likes of PwC.

That appears to be what Lieben has in mind. After all, it’s what he did with the Trademark Clearinghouse almost a decade ago — building it independently with Deloitte while the new gTLD rules were still being written and then selling the service to ICANN when the time came.

The TieredAccess service is described in some detail here.

Court rules domain name list should stay secret

Publishing a list of every domain name in their zone is something that most TLD registries do automatically on a daily basis, but a court in Chile has ruled that doing so is a cybersecurity risk.

NIC Chile, which runs .cl, said last week that it has won an appeal against a Transparency Council ruling that would have forced it to publish a list of the domains it manages.

The Court of Appeals ruled that the registry was within its rights to refuse to hand over an Excel spreadsheet listing the 575,430 domains in .cl to the person who requested it.

The request was just for the list of domains, with none of the other data you’d find in a zone file and no Whois information about the registrants.

Nevertheless, the court unanimously ruled that to hand over the list would present “cybersecurity risks”, according to NIC Chile attorney Margarita Valdés Cortés.

NIC Chile said in a statement:

In this particular case, it was considered that the bulk delivery of domain names to a private individual could generate risks of cybersecurity of various kinds, both in access to information as a result of those domain names as well as the possibility that, by having such a list, attacks on servers, phishing, spam or others could be made easier. Similarly, the ruling of the Court of Appeals understood that the delivery of the data affects commercial and economic rights of the holders of these .CL domains, and considered that there is a legal cause that justifies NIC Chile´s refusal to turn over the list of all registered names.

Cortés said that the case will now go to the nation’s Supreme Court for a final decision, after the Transparency Council appealed.

Access to zone files is considered by many security researchers to be an invaluable tool in the fight against cybercrime.

NIC Chile has published the ruling, in Spanish, here (pdf).