For those of us in the domain name industry, it’s clear that security threats and the way we track, report, and mitigate them has been a topic of increased discussion and focus in recent months.

As we prepare to come together as a community again at the next ICANN public meeting in Marrakech, many of us will look to continue these conversations, as there is no doubt it is a topic of importance, relevance and urgency for our community at this time.

That said, while this critical subject is high on many people’s agendas, our discussions often struggle due to a lack of common definitions or understanding about some of the key points and language we use. When considering metrics, research projects, and contracted party efforts, it may be beneficial for us to step back and ensure we’re all ‘speaking the same language.’

Any meeting is more productive when it has an agenda. Ensuring we’re clear on the topic we’re discussing, what we mean by the terms we use and what we’re trying to achieve will ensure we are in the best possible position for productive collaboration towards a clear goal.

Why is abuse such an important topic for registry operators?

The most basic answer to this question is compliance with the ICANN Registry Agreement. Registry Operators have a contractual obligation under Specification 11 of the Registry Agreement to analyze and report on the security threats in their TLDs.

In particular, Specification 11 Section 3(b) states that Registry Operators “...will periodically conduct a technical analysis to assess whether domain names in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets,..” and will “...maintain statistical reports” on these threats and the action taken to address them.

ICANN published an Advisory on this section of Spec 11 in 2017, indicating that there was some degree of concern or confusion among Registry Operators at the time as to how they could remain compliant with the section.

But beyond Specification 11, there are a number of business, operational, reputational and even financial reasons why a Registry Operator should maintain a focus on monitoring and mitigating abuse within their TLD.

Ultimately the potential consequences of getting this wrong could be widespread and negatively impact the public and communities we support; from dissemination of illegal material all the way up to national security threats.

As our conversations mature and progress on this subject, it’s important, we continue to check in and ensure we’re reading from the same playbook and have a common understanding of the issue at hand.

What actually is ‘abuse’ and who’s responsible?

One major issue with this subject is the interchangeable use of terms such as ‘DNS abuse’, ‘domain name abuse’ and other similar phrases, and a common understanding of what the terms mean.

At the GDD Summit in Bangkok, there was a double session intended to facilitate discussion on systematic DNS abuse issues impacting the DNS industry ecosystem—but the general consensus was that there is simply no commonly-accepted definition of abuse within our multi-stakeholder community.

It is hard to have a productive conversation if we aren’t agreed on what we mean by the topic.

The added layer of confusion or debate comes from determining which issues fall into which parties’ remit. For example, while ICANN’s mission is to ensure stable and secure operation of unique identifier systems, and it generally considers abuse to fall within its remit in this regard, in practice its enforcement is more narrowly defined and limited to the requirements of its agreements with contracted parties. Similarly, Registry Operators and Registrars must establish what responsibilities or obligations they have beyond their ICANN relationship or contractual requirements, and what their role is in combatting these.

ICANN’s Domain Abuse Activity Reporting (DAAR) project outlines four key kinds of abuse it identifies and tracks; phishing, malware, botnet command-and-control, and spam. These mostly align with the threat types specified in Section 3(b) of Specification 11—with the exception of spam, which doesn’t fall within the scope of Specification 11 and therefore isn’t within ICANN’s remit for enforcement (in fact, ICANN has specifically indicated that spam is outside its authority entirely).

Even once we’ve established a list of abuse types, the ways we take action against them and the approach to mitigating them may also differ considerably. The beauty and the curse of a multi-stakeholder model is that various parties can hold different, and sometimes conflicting views or understandings of key subjects, so it’s important to establish what is black-and-white, and where we’re working with shades of gray.

So how do we track and measure abuse?

Perhaps the most pressing subject is identifying methods of tracking, measuring and reporting abuse.

To meet the requirements of Specification 11, many Registries use systems or tools to conduct technical analysis and identify domain names that may be involved in security threats or malicious activity. This often involves monitoring data threat sources, each of which may offer a varying level of detail or information on the threat itself.

Before we select these tools and sources however, it’s important to first establish why we’re tracking this activity in our TLDs.

If the purpose is to provide statistical reports on domain abuse activity for general research purposes, some data sources can provide an overall view of the zone without any specific detail. However, more detailed threat information, including the full URL of specific threats, is necessary for verification and remediation efforts for phishing, malware and botnet activity. These URLs can allow reports to be verified and compromised systems cleaned, by providing the exact location of phishing webpages and malicious binaries. So the sources that work for research, aren’t always suitable for verification and mitigation—nor is any one of these sources more ‘correct’ or more ‘complete’ than another.

For example, the data sources used within DAAR are similar to an extent to some of those used within the Registrar community. However systems such as these are often designed to meet unique requirements, for example as part of a research project or as a tool in security processes, and the sources and processing of this data may vary within these systems. This can result in differing statistical results.

Similarly, many companies (such as Neustar) have developed their own methods for tracking, reporting and verifying threats, and exercise these with varying levels of enforcement. The data these tools generate may differ from each other, from ICANN/DAAR’s data, or from other sources—but again, there is no ‘one true source’ that is the defensible standard in this realm. Ultimately, the choice of source, tool, or system comes back to asking ‘What are we trying to find out?’ and ‘What are we looking to do with this information?’

Where to from here?

Regardless of what we call it, it is clear that domain abuse will continue to be a topic of discussion within the ICANN community. ICANN’s goal—as an organization and as a broader community in which we all participate—is to ensure a safe and secure online environment. And while the language we use may prove complex at times, it’s encouraging that these conversations are continuing, and are being given the focus and weight that they deserve.