Authors:
Siôn Lloyd, Principal Security, Stability, and Resiliency Scientist
Sam Cheadle, Machine Learning Engineer
Carlos Hernandez Gañán, Principal Security, Stability, and Resiliency Scientist
There have been ongoing discussions about the volume of domains involved in Domain Name System (DNS) Abuse, including but not limited to a recent report by the Interisle Consulting Group in which they examined the number of newly registered generic top-level domains (gTLDs) which the report classified as being registered for malicious use. While we do not fully agree with some of the scales and metrics portrayed by this specific report, we appreciate how it has contributed to ongoing discussions within the ICANN community regarding the current DNS Abuse landscape, and the difficulties that come when measuring and mitigating it. These conversations are valuable, and they highlight that different studies can arrive at different estimates of malicious domain registrations; the results depend on how abuse is defined, what level of evidence is required before a domain is considered malicious, and how the data are analysed to estimate the total number of malicious domains.
In this blog, we focus on three aspects of the ongoing ICANN community discussions concerning DNS Abuse:
- The difference between reported and block-listed domains versus confirmed malicious domains.
- The scope of ICANN's definition of DNS Abuse.
- The importance of methodology, reproducibility, and context.
Reported Versus Well-Evidenced DNS Abuse
There is a difference between a domain that has been reported as malicious (or suspicious) and a domain with actionable evidence against it that supports a reasonable determination that the domain is being used for DNS Abuse. This distinction matters most when looking at specific cases, and is critical when assessing what mitigation steps might be required. When thinking about statistics and trends, such as those presented in the report, the distinction still matters – statistics can inform policy, so we must be clear about the limitations of any claims being made. This is why it is possible to use reputation block lists (RBLs) to analyze patterns seen in reported abuse (understanding the limitations of the data); however, actions such as domain suspension typically require investigation or corroboration.
ICANN's Definition of DNS Abuse
ICANN's contractual definition of DNS Abuse is narrow to ensure that any actions ICANN takes in this area are within ICANN's remit. This definition covers botnets, malware, pharming, phishing, and spam (when used as a vector for one of the harms listed above). In arenas outside the ICANN ecosystem, parties often consider problematic Internet activity that is outside ICANN's remit. That other parties include additional or different categories beyond ICANN's remit such as fraud, or scams, for example, is understandable. ICANN notes that some country code top-level domains (ccTLDs) that are not bound by ICANN contracts include these abuse types.
When online abuse is being discussed, it must be made clear what type of abuse is being included and why. Further, the consequences of including lower-confidence reports must be communicated and understood, because including data about reported (as opposed to confirmed) abuse means that volumes can be inflated, as statistics on reported abuse at best form an upper limit to the amount of confirmed abuse. As an example, if a broader definition of spam is considered as an abuse type (meaning, spam beyond that included in the ICANN DNS Abuse definition, which is limited to spam used to disseminate other types of DNS Abuse within ICANN's remit), the data also will include domains that may not be actively harmful. In this example, we see emails advertising casinos, which may or may not be real, and which may or may not be legal (something that may depend on where they operate, and where the user lives). These sorts of emails likely would not fit within the ICANN definition of DNS Abuse. This more broadly defined spam category also often includes entries that are not based on direct observations of behavior, that is predictive or heuristic entries, which further separates reports from evidence.
References to Other Research Methodologies
When building on a published methodology, it is important to clearly describe any changes that have been made. This allows others to understand, reproduce, and evaluate the results.
The Interisle report does a good job of describing the methodologies used for finding associated domains, saying that their methodology shares similarities with the published ICANN Office of the Chief Technology Officer method. However, the analysis described in the report differs from the published ICANN method, and those differences are not explained. The same is true of the method used to classify domains as being maliciously registered, where it shares similarities with COMAR, but the differences are not made clear. Because the assumptions and implementation details affect the resulting estimates, simply citing the methodology is not enough. Any modifications should be clearly documented so readers can understand how the results were derived.
Conclusion
We welcome continued discussion on these issues. ICANN recognizes the harms associated with DNS Abuse and takes its role seriously in supporting mitigation efforts within the scope of its mission and responsibilities. This is exactly why the community is currently working through policy development processes (PDPs) to address malicious domain registration, via the associated domain check PDP, which will be followed by a PDP that seeks to introduce safeguards for new account holders' abilities to register domains at scale.
ICANN is driven by the bottom-up stakeholder model and we encourage all sections of the community to bring ideas forward, helping us to make the Internet a safer place for all.