Introduction

The landscape for reporting DNS abuse to registrars and registries has become fractured in the wake of the 2024 implementation of changes to their contracts. Some entities only accept abuse reports via email, some only through a webform, and some take both. This inconsistency has created a significant barrier for those trying to get abusive domains taken offline.

The Digging DNS Abuse Contacts list is an open-source, community-driven attempt to document and track how registrars and registries accept abuse reports, with the goal of making the process clearer for everyone.

Access the Project

View the list and contribute on GitHub.

Objective

To create an open-source, comprehensive, and collaborative, up-to-date list of where and how to send DNS abuse reports to every registrar and registry.

The History of the Problem

In April 2024, ICANN, its registrars, and its registries began enforcing a voted-upon change to their respective contracts which both clarified and raised requirements for acting on DNS abuse. Simultaneously, the amendments changed how these entities could accept abuse reports, adding a potent "or" statement to their obligations: they must provide an email address or a webform.

Prior to the widespread adoption of modern LLMs and AI, processing email-based abuse reports was a massive resource drain for registrars and registries. The efforts involved significant human and machine time, and the results were often slow and error-prone. These operations were purely a cost center on a multitude of fronts: the labor to review reports, the money lost on fraudulent registrations, machine time, and licenses for help desk systems. Sure, these entities had contractual, legal, and perhaps ethical obligations, but that didn't mean they were happy sinking money into it.

Yearning for a way to process data more quickly and uniformly, the Contracted Parties House (CPH - the registrars and registries combined) proposed allowing abuse submissions through webforms. The idea was that this would structure the incoming information in a standardized way that could integrate better with their systems and cut down on the complexities and costs of processing free-form emails.

Keep this timeline in mind: this proposal came about in November 2022 and went into effect in April 2024. ChatGPT, which revolutionized how we think about processing unstructured text, was released in late November 2022, right as this was being debated.

The Path to Hell is Paved with Good Intentions

NOTE: I was not a direct party to any of the conversations about these amendments, so I cannot attest to if the following issues were discussed or considered. I can only comment on the outcome we live with now.

Regrettably, the contract amendments are void of one key detail: standardization. Each registrar and registry that elected to use the webform route was free to implement it however they saw fit. This led to a complete lack of consistency in areas such as:

• How reporters are notified of a switch from email to a webform.
• The location of the webform (e.g., abuse.example.com vs nic.tld/report-abuse).
• What kind of details to collect for each abuse type.
• How submission status is communicated back to the reporter.
• And crucially, there is no master list of all these unique abuse forms.

Now, one could argue that setting such requirements is onerous. The counter to that is that these entities are already required to maintain compliance with far more complex and technical standards. In many ways, standardizing a few webform fields is arguably simpler than ensuring compliance with the intricacies of the RDAP protocol.

More than a year after these changes went into effect, the new system has undoubtedly made operations easier for many registrars and registries. Some are boasting faster turnaround times on abuse reports and are able to spend less effort on this part of their contractual obligations. But some of this "efficiency" might simply stem from the fact that they are not receiving the volume of reports they used to. I once had a colleague at another company complain to me that they had no desire to change their processes to submit to a webform, and that it was on us to "RTF(e)M(ail)."

Somewhat inadvertently, billions of dollars worth of industry, an untold number of security researchers, and average netizens may now find that the process for reporting abuse has suddenly changed or become too burdensome. One could argue that the drive to streamline abuse mitigation has resulted in a temporary, but significant, step backwards, as some abuse may no longer get reported at all.

And thus, those of us reporting abuse have found ourselves in a special kind of hell. How do I report this? Can I automate any of it? When will the next registrar switch its process without warning? The intentions were good. The outcome is chaos.

To Be Clear

I'm not blaming, faulting, or accusing any single entity. I certainly don't fault registrars and registries for wanting to improve their internal processes. I'm glad they have a stated goal of mitigating abuse faster and with clearer definitions. Those of us reporting abuse should want to support such an initiative. The problem is the fractured implementation.

Existing Solutions

I am aware of at least two other solutions within the DNS industry that are also attempting to address parts of this problem. They are both excellent initiatives worth knowing about.

The NetBeacon Institute

Public Interest Registry (the operator of the .org TLD) created The NetBeacon Institute to address a resource "gap and a more general need for innovation, education, and collaboration on DNS Abuse." One of its major features is a centralized abuse reporting tool. The idea is that anyone can report abuse through the tool, and NetBeacon will route the report to the appropriate registrar and/or registry. It offers integrations for both high-volume reporters and for registrars/registries to streamline the entire process. You can read more about it here.

The Abuse Contact IDentifier (ACID) Tool

Created by ICANN's Registrar Stakeholder Group (RrSG), the ACID tool performs several lookups against a domain's WHOIS and DNS records to help a user find the right place to direct an abuse report. It's a useful lookup tool, though if it returns an email address that a registrar no longer monitors, it may inadvertently create duplicative work for the reporter.

The Digging DNS Abuse Contacts List

Sometimes, you just want a simple guide with a simple answer, without fancy lookups or workflows. My project aims to be just that: a straightforward, community-curated list. Until this oversight in the ICANN contracts is remediated with a standardized, official solution, I have created a starting point that I hope can solve this problem with the help of the community.

My hope is that this project is a temporary stopgap measure. But until an official one is implemented, let's work together to build the resource we all need.