|
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 are often fit into three broad categories:
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.
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.
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:
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.
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.
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:
Effective | Quick | Simple | Precise | Proportional | Cost-Effective | |
---|---|---|---|---|---|---|
ISP | ✔ | ✘ | ✘ | ? | ✘ | ✘ |
CDN | ? | ? | ? | ? | ✘ | ✘ |
Host | ✔ | ✘ | ✘ | ✘ | ✘ | ✘ |
Platform | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Registrar | ✔ | ✔ | ✔ | ✘ | ✘ | ✘ |
Registry | ✔ | ✔ | ✔ | ✘ | ✘ | ✘ |
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:
Effective | Quick | Simple | Precise | Proportional | Cost-Effective | |
---|---|---|---|---|---|---|
ISP | ✘ | ✘ | ✘ | ? | ✔ | ✘ |
CDN | ✘ | ? | ? | ? | ✔ | ? |
Host | ✘ | ? | ✔ | ✔ | ✔ | ✔ |
Platform | N/A | N/A | N/A | N/A | N/A | N/A |
Registrar | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
Registry | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
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.
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.
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byCSC
Hi Graeme
Thank you for the good work that you are doing at the DNS Abuse Institute. Thank you also for this very useful and insightful matrix - I think it will go a long way to moving the discussion on DNS Abuse forward.
There are many circumstances involving content abuse where, in theory, the parties that have the ability to alter content (the red boxes in your first diagram: host, platform, registrant) are the most appropriate parties to mitigate the harm. However, in practice, it’s often not possible to have the harm mitigated by them, and the DNS parties are then the only ones capable of addressing the abuse in any effective way. For example, fast-flux hosting where the host changes constantly and can’t be pinned down, or the proverbial game of whac-a-mole where one host takes down the content only for another to be spun up by the registrant shortly thereafter; or the presence of a reverse proxy/CDN, making identification of the host near impossible; or recalcitrant or unresponsive hosts.
In situations like that, where in theory the host/platform/registrant are the most appropriate ports of call but where approaching them is not fruitful and the DNS parties are the only ones capable of doing anything meaningful, it seems that the balance of the analysis, based on your seven imperatives (which I agree with), leans towards mitigation by the DNS parties. Obviously, it depends also on the nature of the abuse or content, and considerations of precision and proportionality in circumstances where the abusive content is not the only thing for which the domain is used.
So it seems that the balance of the analysis is difficult to pin down in theory and can shift, depending on how any particular complaint plays out in practice and how the content parties react in any given situation. Do you agree that in some content abuse situations it may be appropriate to look to DNS providers to mitigate the abuse, in circumstances where they are the only ones that can?
Would it make sense to build in some sort of escalation protocol for content abuses, i.e. requiring the complainant to first approach the host/platform/registrant, and only once those have been exhausted unsuccessfully, look to the DNS parties?
Thanks very much for your consideration and keep up the good work!
Jeremy Speres
Thank you for the thoughtful reply Jeremy. I think it's possible to have an array of harms ultimately land at the DNS, but we (and by we, I mean the industry, abuse reporters, and the Institute) need to do a bunch of work first. In order for the DNS to be the mitigation-layer-of-last-resort, we'll need to provide better evidence standards for abuse reporting, better abuse complaint processes, and some best practices on abuse escalation, to name a few. Ultimately I think we could end up in a place where some Registrars, with well-evidenced and a documented escalation history from a reliable Reporter, will feel comfortable taking action on some content harms. I think there are years of work between here and there though, and only some of that work will fall into the purview of the DNSAI.
Thank you for the swift and considered response, Graeme. Godspeed to you and the Institute for the work that lies ahead!
There is another whole category, governance! When the registry manager cancels their contract with the registry operator and has no *documented* plan for the future, one could call that DNS abuse too I think :)