A substantial amount of DNS community discussion on the topic of DNS Abuse is focused on defining what is or is not DNS Abuse. The definition adopted by ICANN contracted parties, as well as the DNS Abuse Institute, is straightforward: DNS Abuse is malware, botnets, pharming, phishing, and spam where it’s a vehicle for the preceding harms. There is, of course, some fuzziness on the margins, where technical harms are also using content.

The reasons for the definitional discussion are straightforward—most Registrars and Registries want a narrow definition of technical harms that they can understand and have the capability to address, and which also limits the impacts of an imprecise and often disproportionate approach. Whereas other interests are typically interested in an expanded definition in the hopes that the harms impacting them can be addressed at the only centralized and globally regulated component of the Internet’s infrastructure, the DNS.

This post is a thought experiment intended to provide a new alternative method for defining DNS Abuse - and the criteria to most effectively mitigate it. Our current definition of DNS Abuse was arrived at by identifying and categorizing online harms based on how the harm is executed. Instead, we propose that a definition could be derived by considering the attributes of how a harm can be mitigated. Through this approach, DNS Abuse is not a list of harms selected by their category, but instead consists of harms that are appropriately mitigated by the DNS. The rest of this post is an elaboration of what appropriate means in this context.

Online Harms

Online harms are often fit into three broad categories:

• Content Harms: Transgressive content such as hate speech, intellectual property infringements like copyright and trademark, and financial or commercial harms like fraud.
• Technical Harms: Botnet Command and Control Infrastructure, the distribution of malware, and DNS poisoning attacks like pharming.
• Hybrid Harms: Phishing and pharming will often have both deceptive content and domain names.

While the categories are useful, it’s important to recognize that online harms may employ combinations of content and technical methods. This categorization is not intended to be definitive, but is helpful to recognize that there are a diverse array of harms and that they employ different techniques.

It’s also worth noting that all online harms (with the exception of spam) involve resolution to (translating an address to the physical file location) a hosted resource. That resolved resource could be a tweet, a web page used for phishing, or the management tools for controlling a botnet. In some sense, these are all types of “content” in that they are files on a server, and that they are distinct from the domain name.

Internet Infrastructure and Online Harms

There are quite a few layers of Internet infrastructure between an end user and a piece of content or harmful file. A simplified map looks like this:

The relevant features of this basic map are that entities in red boxes are likely to have the ability to alter content, and the boxes with fine dotted lines (CDN, Platform, Domain Reseller) may not be present in all scenarios. Blue boxes will usually have control over the resolution of a domain name.

Now that we have a sense of what harms exist, and a rough map of Internet infrastructure, we can begin to consider what pieces of this infrastructure are integral to different categories of online harm.

A clear content harm—for example, a threatening post on Twitter—may only have the platform as integral. All the rest of the infrastructure is involved in making the tweet available, but it should be reasonably obvious that only the platform is the appropriate place to mitigate the harm.

On the opposite end of the online harm, spectrum are harms that are entirely (or almost entirely) technical, like Botnet Command and Control infrastructure. In these circumstances, the domains associated with a botnet are identified, often before registration, and can be best addressed by the registry or registries. The host(s) are also critical but are easily changed by the perpetrator.

The point of these examples is to highlight that different harms rely on different layers of internet infrastructure. Given these patterns, it follows that the methods employed to mitigate harms should employ approaches appropriate to the integral components on which specific harms rely.

Assessing Mitigation

With that background, we can discuss the key piece of this puzzle, and the point of this post, which is that it is simpler to assess mitigation approaches than it is to attempt to categorize and define each type of harm.

So how do we assess mitigation approaches, and what are the attributes that mitigation should have?

Mitigation techniques ought to be:

• Effective – the harm is mitigated
• Quick – the mitigation can be implemented with due speed
• Simple – the harm can be mitigated without involving multiple layers, players, or technologies
• Precise – there is a minimum of collateral damage
• Proportional – the effort and scope of the mitigation is commensurate with the harm
• Cost effective – the cost of mitigation should be commensurate with the the harm
• Necessary – other mechanisms for mitigation are not available

There is, of course, some subjectivity to these attributes, especially in proportionality, but there is little need for belabouring them in a good-faith discussion of online harms. Further, by employing the full set of attributes, we’re able to determine exactly where disagreements about harm mitigation lie. Having collective clarity on where there’s alignment, and where there is not is valuable, and currently missing.

Registrar and Registry Abuse Mitigation Tools

It should be noted that a key consideration for registrars and registries when mitigating abuse is the simplicity of the tools or techniques available to them. The Internet and Jurisdiction Policy Network provides a thorough explanation of available responses in their domain toolkit available here: https://www.internetjurisdiction.net/domains/toolkit. However, the only real tool a registrar or registry has is to prevent a domain name, and consequently any services that rely on it, from resolving.

It is for this reason that resolving a harm via registrars and registries is often neither precise nor proportional. Further, a registrar or registry may have no way to determine if a domain name is providing other services making proportionality assessments difficult if not impossible.

Bringing it Together

We’ve established that different online harms use different infrastructure, and that mitigation techniques have a reasonably defined set of desirable attributes. The next step is to put these two pieces together to determine if mitigating harm at a particular layer is appropriate.

To do so, we return to our initial two examples, this time in the form of a matrix where we assess each layer of internet infrastructure by the above attributes.

For our hateful tweet example:

From this analysis we can determine that mitigation on the platform itself is the most desirable approach. Mitigating a hateful tweet by having the registrar suspend twitter.com will be quick and can prevent the tweet from being seen, but it’s neither precise nor proportionate. Having ISPs around the world block a specific tweet might work, but it is not going to be quick, simple, cost-effective, or proportionate.

Applying the same analysis to Botnet Command and Control Infrastructure:

Here we can see that while mitigating a botnet at the host level may be reasonably simple and precise, it’s likely not effective because the hosting infrastructure can be rapidly changed. The primary benefit of resolving botnets at the registry rather than registrar is that domains may be blocked at the registry with minimal cost, and potentially prior to registration which saves fees and reduces harm.

Summary

While the DNS Abuse Institute is not about to embark on a campaign to redefine DNS Abuse, we are interested in approaches that increase our understanding of the problem and bring greater sophistication to community discussions about DNS Abuse.

When someone suggests a problem should be resolved at the DNS layer, this alternative DNS Abuse approach allows us to ask why mitigation at this level is appropriate and provides us with a framework for assessing the response. We can also have discussions about the relative weights of each mitigation attribute, and whether they change based on the specific type of harm. As well, in this approach, new online harms are relatively easily assessed, and a new definition need not be discussed and adopted.

We also gain clarity on which parts of the Internet ecosystem require more attention, and even potential regulation. An abundance of scenarios exists where the host is the appropriate place to mitigate a harm, and an unfortunate lack of mechanisms to address abuse at this level of infrastructure.

Lastly, by recognizing the strengths and weaknesses of various approaches to mitigation we are better able to understand where the DNS Abuse Institute can assist Registrars and Registries to take action.