[ad_1]
A substantial amount of discussion in the DNS community on the topic of DNS abuse centers around defining what is and is not DNS abuse. The definition adopted by ICANN contracting parties, as well as the DNS Abuse Institute, is simple: DNS abuse refers to malware, botnets, pharming, phishing, and spam where it is a vehicle. for previous damage. There is, of course, some blurring on the fringes, where technical mischief also uses content.
The reasons for the definition discussion are simple: most registrars and registries want a narrow definition of technical damage that they can understand and have the capacity to deal with, and which also limits the impacts of an approach. imprecise and often disproportionate. While other interests are generally interested in an expanded definition in the hope that the damage that affects them can be addressed at the only globally centralized and regulated component of the Internet infrastructure, the DNS.
This article is a brainstorming experiment intended to provide a new alternative method for defining DNS abuse – and the criteria for mitigating it most effectively. Our current definition of DNS abuse was achieved by identifying and categorizing harm online based on how the harm is executed. Instead, we propose that a definition can be derived by considering the attributes of how harm can be mitigated. With this approach, DNS abuse is not a list of damages selected by their category, but rather consists of damages that are appropriately mitigated by the DNS. The remainder of this article is an elaboration of what appropriate means in this context.
Online damage
Online harms are often categorized into three broad categories:
- Harmful Content: Transgressive content such as hate speech, intellectual property violations such as copyright and trademarks, and financial or commercial harm such as fraud.
- Technical damage: Botnet command and control infrastructure, malware distribution, and DNS poisoning attacks like pharming.
- Hybrid damage: Phishing and pharming will often have both deceptive content and domain names.
While categories are useful, it’s important to recognize that online prejudices can use combinations of content and technical methods. This categorization is not meant to be definitive, but is helpful in recognizing that there is a wide range of harms and that they use different techniques.
It should also be noted that all online damage (except spam) involves the resolution (translating an address to the physical location of the file) of a hosted resource. This resolved resource can be a tweet, a web page used for phishing, or management tools to control a botnet. In a sense, these are all types of “content” in the sense that they are files on a server and are separate from the domain name.
Internet infrastructure and online nuisance
There are multiple layers of Internet infrastructure between an end user and a harmful piece of content or file. A simplified map looks like this:
The relevant features of this base map are that entities in red boxes are likely to have the ability to edit content, and boxes with thin 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 an idea of ​​the existing harms and a rough map of the Internet infrastructure, we can begin to examine which elements of that infrastructure are integral to the different categories of harm online.
A prejudice of clear content, for example a threatening post on Twitter, may have the platform only as an integral part. 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 right place to mitigate the damage.

In contrast to online harm, the spectrum is made up of entirely (or almost entirely) technical harm, such as botnet command and control infrastructure. In these circumstances, the domains associated with a botnet are identified, often before registration, and may be best handled by the registry (s). The host (s) are also critical but are easily changed by the author.

The purpose of these examples is to emphasize that different damages depend on different layers of Internet infrastructure. Given these trends, it follows that the methods employed to mitigate damage should employ approaches appropriate to the integral components upon which specific damage is based.
Mitigation assessment
Against this background, we can discuss the centerpiece of this puzzle and the point of this article, which is that it is easier to assess mitigation approaches than to try to categorize and define each type. of prejudice.
So how do we assess mitigation approaches and what attributes should mitigation have?
Mitigation techniques should be:
- Effective – damage is mitigated
- Fast – mitigation can be implemented quickly
- Simple – damage can be mitigated without involving multiple layers, actors or technologies
- Accurate – there is minimal collateral damage
- Proportional – the effort and extent of mitigation are proportional to the harm
- Cost effective – the cost of mitigation should be proportional to the harm
- Necessary – other mitigation mechanisms are not available
There is, of course, a certain subjectivity in these attributes, especially in terms of proportionality, but there is little need to stress them in a bona fide discussion of online harm. Additionally, by using the full set of attributes, we are able to determine exactly where the disagreements about damage mitigation lie. Having collective clarity on where there is alignment and where there is not is valuable and currently lacking.
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 detailed explanation of the answers available 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 the resolution of a domain name, and therefore of all the services that depend on it.
It is for this reason that the resolution of a prejudice through registrars and registers is often neither precise nor proportionate. Additionally, a registrar or registry may have no way of determining whether a domain name provides other services, making proportionality assessments difficult, if not impossible.
Bring together
We have established that different online damage uses different infrastructures 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 damage mitigation to a particular layer is appropriate.
To do this, we return to our first two examples, this time in the form of a matrix where we evaluate each layer of the Internet infrastructure by the above attributes.
For our example of a hateful tweet:
Effective | Quickly done | Simple | Precise | Proportional | Profitable | |
---|---|---|---|---|---|---|
ISP | ?? | ?? | ?? | ? | ?? | ?? |
CDN | ? | ? | ? | ? | ?? | ?? |
Host | ?? | ?? | ?? | ?? | ?? | ?? |
Platform | ?? | ?? | ?? | ?? | ?? | ?? |
Clerk | ?? | ?? | ?? | ?? | ?? | ?? |
Registration | ?? | ?? | ?? | ?? | ?? | ?? |
From this analysis, we can determine that mitigation on the platform itself is the most desirable approach. Mitigating a hateful tweet by asking the registrar to suspend twitter.com will be quick and may prevent the tweet from being seen, but it is neither precise nor proportionate. Having ISPs around the world blocking a specific tweet may work, but it won’t be quick, simple, profitable, or proportionate.
Applying the same analysis to the botnet command and control infrastructure:
Effective | Quickly done | Simple | Precise | Proportional | Profitable | |
---|---|---|---|---|---|---|
ISP | ?? | ?? | ?? | ? | ?? | ?? |
CDN | ?? | ? | ? | ? | ?? | ? |
Host | ?? | ? | ?? | ?? | ?? | ?? |
Platform | N / A | N / A | N / A | N / A | N / A | N / A |
Clerk | ?? | ?? | ?? | ?? | ?? | ?? |
Registration | ?? | ?? | ?? | ?? | ?? | ?? |
Here we can see that while the mitigation of a botnet at the host level can be reasonably simple and precise, it is probably not effective because the hosting infrastructure can be quickly changed. The main benefit of resolving botnets at the registry rather than at the registrar is that domains can be blocked at the registry at minimal cost, and potentially before registration, saving costs and reducing damage.
Summary
While the DNS Abuse Institute is not about to embark on a campaign to redefine DNS abuse, we are interested in approaches that improve our understanding of the problem and bring greater sophistication to community discussions on issues. DNS abuse.
When someone suggests that an issue needs to be resolved at the DNS layer, this alternative approach to DNS abuse allows us to ask Why mitigation at this level is appropriate and provides us with a framework to assess the response. We can also have discussions about the relative weights of each attenuation attribute, and if they change depending on the specific damage type. Moreover, in this approach, new online harms are relatively easy to assess and a new definition does not need to be discussed and adopted.
We’re also clarifying which parts of the internet ecosystem need more attention, and even potential regulation. There is an abundance of scenarios where the host is the right place to mitigate harm, and an unfortunate lack of mechanisms to address abuse at this level of infrastructure.
Finally, by recognizing the strengths and weaknesses of various mitigation approaches, we are better able to understand where the DNS Abuse Institute can help registrars and registries take action.
[ad_2]