The Ever-Evolving Problem of DNS Abuse

For several years, many within ICANN circles have raised concerns about the escalating nature of domain name system (DNS) abuse. While some strides were made toward a safer DNS, new data—this time from a comprehensive study of DNS abuse by the European Union—demonstrates that abuse remains a frustratingly obstinate problem that requires urgent attention.

We’ve seen some registries and registrars testing innovative industry-led initiatives in an effort to address the issues. Unfortunately, as recognized by the European Union and others, these have taken us only so far. Much more is required of ICANN—the global coordinator of DNS policy—to take on this problem and make a measurable dent by adopting the common-sense recommendations in the EU report.

The longstanding abuse problem persists

As the EU report highlights, DNS abuse cuts a wide swath. The report analyzed 1.68 million abused names1—a staggering number that even without further context represents pervasive abuse rates. Actions of bad actors show no signs of abating.

Interestingly—and industry insiders have known this for some time—abuse tends to concentrate in certain top-level domains (TLDs) and/or with certain registrars. According to the EU study:

  • The two most abused new gTLDs together account for 41% of all abused new gTLD names in the second quarter of 2021.
  • The top five most abused registrars account for 48% of all maliciously registered domain names.

As mentioned, voluntary industry measures are laudable, but their reach is constrained. In fact, two of the three “most abused” registrars are signatories to the DNS Abuse Framework, the industry initiative launched in 2019 to try to mitigate abuse.

Building on the EU findings, our experience at Appdetex managing enforcement efforts for major brands and companies shows further that while worthy of applause, industry self-regulation goes only so far. As part of our service, we often notify registrars and registries of DNS abuse, following the procedures spelled out in the DNS Abuse Framework. The results, unfortunately, suggest that known abuse often goes unaddressed, and even signatories to the framework lag in their responses to abuse notifications—or in some cases, abuse complaints are outright ignored. In 2021, for example, we found that some registrar abuse complaint mitigation rates ranged as low as 25% of submitted notifications; even for framework signatories and for non-signatories sometimes the rate hovers at 0%. Registry framework signatories were more active in their mitigation work, with a much higher resolution rate of 93%, though again, non-signatory rates were worse, at only 34%.

Debates over definitions stall action

As a precursor to considering mitigation strategies, a working definition of DNS abuse has long been debated. Domain name registries and registrars—known in the ICANN sphere as contracted parties—have sought to exactingly limit the definition to malware, botnets, phishing, pharming and spam (as a method of distributing the first four types of abuse). Contracted parties argue this is appropriately scoped.

Naturally, this doesn’t address all forms of abuse. But then, what is abuse, if not only the above? One could recall as an analogy the U.S. Supreme Court Justice Potter Stewart, who famously said about trying to define obscenity:

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description … But I know it when I see it.

Similarly, it would be difficult to believe this industry doesn’t know domain name abuse when it sees it, and accordingly, abuse cannot reasonably be limited to an over-restrictive definition. To do so would be to ignore the changing nature of abuse and the new abuse vectors that emerge. As ICANN’s Security and Stability Advisory Committee (SSAC) noted in SAC115 (emphasis added):

These categories have been adopted within the ICANN realm in specific contracts, but do not represent all forms of DNS abuse that exist, are reported, and are acted upon by service providers. New types of abuse are commonly created, and their frequency waxes and wanes over time. Thus, no particular list of abuse types will ever be comprehensive.

If the community insists on defining abuse, that definition must be suitably broad enough to remain flexible and responsive to the evolution of abuse. So far, however, ICANN Org and contracted parties have not taken up the advice of the SSAC experts appointed to provide, well, expert advice. Thus, while some are hung up on a restrictive definition, the bad guys are getting smarter and more prevalent.

Conversely, the EU report finally proposes a definition of DNS abuse that is appropriately inclusive:

Domain Name System abuse is any activity that makes use of domain names or the DNS protocol to carry out harmful or illegal activity.

No doubt, some will balk at definitional inclusivity and tell us that too wide a definition is unworkable. But as we’ve seen, a too-narrow definition hasn’t helped solve what is a very wide problem, either. It would be wise to define more broadly and, if necessary, narrow over time.

Warnings have been brushed aside for over six years

Security experts not only have long warned about abuse but have prescribed various ways to at least begin to address it. For instance, more than six years ago, in SAC077, the SSAC wrote (emphasis added), about ICANN’s proposed marketplace health index:

The SSAC notes that to develop and maintain effective metrics of security and stability of the gTLD ecosystem, ICANN will have to undertake auditing activity, including mandating future disclosure of aspects of registry and registrar operations and behavior, in a form that emphasizes consumer protection over industry norms.

This is something ICANN Org has not done. In fact, it’s been made clear to the community from various directions that ICANN is woefully behind on its deliverables to the community—including those like the above, intended to inform all of us about the health of the DNS and where fixes are advisable.

Even as recently as 2020, during the opening of the COVID-19 pandemic when abuse rates spiked upward, industry observers pointed to the community’s response to security threats and abuse, labeling it as “weak tea.”

This industry has some catching up to do, or it will see solutions imposed on it.

What CAN be done about DNS abuse

The EU report calls for some reasonable practices registries and registrars can and should take to mitigate DNS abuse. These include:

  • Verifying the accuracy of domain name registrant data;
  • Developing tools for identification of names that infringe on intellectual property rights;
  • Using predictive algorithms to prevent abusive registrations;
  • Monitoring abuse rates with the cooperation of regulatory bodies and independent researchers; and
  • In conjunction with ICANN Org, be financially rewarded for lowering abuse rates.

There’s little reason contracted parties and ICANN Org can’t take these steps today in the name of DNS health.

The EU study’s authors recommend further steps toward abuse mitigation:

  • Public identification of registries and registrars with higher-than-normal rates of DNS abuse;
  • Revocation of accreditations for those whose abuse rates continually exceed predetermined thresholds;
  • Employment of DNSSEC; and
  • Harmonization by gTLDs of the regulations and practices of ccTLDs with lower rates of abuse.

These last four steps are not out of reach, either. We know the Danish .DK registry has been inordinately successful in keeping abuse at bay, mainly by verifying the identity of its registrants. The .EU registry employs an anti-abuse mechanism known as APEWS, which allows domain name registrations to proceed but pre-emptively identifies potential problem registrants.

Even a few forward-thinking entities are more proactive about anti-abuse measures. Radix Registry, for example, reviews registrations for potential abuse. Among other steps, Radix reserves rights to cancel a domain registration:

  • where the Registered Name Holder fails to keep Whois information accurate or up-to-date;
  • if the Registered Name use is abusive or violates the acceptable use policy, or a third party’s rights or acceptable use policies, including but not limited to the infringement of any copyright or trademark; or
  • where the Registered Name is found to have been registered as part of a set of any pattern-based registration which has shown abusive trends in the past, or is part of a present or ongoing abusive campaign, including but not limited to domains registered using any domain generation algorithms, scripts, dictionaries, etc., whether detected by Radix or a registrar.

Most registrars and gTLD registries have yet to employ these types of implementable solutions, even as their effectiveness has been widely demonstrated.

Conclusion

It’s obvious that ICANN is overburdened as an organization, to say the least. However, ICANN Org must prioritize its workload in an effort to stave off further governmental incursion, volunteer burnout, and frustration with lack of outcomes. In this instance, the EU report is chock full of facts and practical suggestions ICANN can immediately deploy, and ICANN is well overdue to take a hard stand against DNS abuse.

The concern is that ICANN Org and industry will continue with their messaging to date—that only so much can be done with (by ICANN Org’s admission) weak contractual enforcement provisions, that contracted parties aren’t in a position to take wider action against DNS abuse, and that various roadblocks prevent meaningful measures.

The time for excuses has passed. The DNS community, suffering from a deluge of abuse and without much recourse in the face of intransigence, needs action from contracted parties and ICANN Org. The EU report is a great place to start, and we look forward to good faith engagement in exploring its anti-abuse recommendations.

  1. European Commission, Directorate-General for Communications Networks, Content and Technology, Paulovics, I., Duda, A., Korczynski, M., Study on Domain Name System (DNS) abuse, 2022, https://data.europa.eu/doi/10.2759/616244 (p.53)  



Menu