What is DNS abuse?

DNS abuse is any harmful activity that exploits domain names or the DNS protocol, but defining exactly what qualifies, who should act, and how to respond without causing collateral damage has been one of the most divisive questions in internet governance. This guide covers the competing definitions, the key distinctions that determine appropriate response, and the governance framework that has emerged.

8 min read

What it is#

DNS abuse is a broad term for harmful activity that involves the Domain Name System, whether the DNS is the direct target of an attack, the infrastructure that enables it, or simply the addressing layer that connects victims to malicious resources. The concept is straightforward in the abstract, but in practice it has been one of the most contentious topics in internet governance for over a decade.

The difficulty is not identifying that harm exists. It is deciding where the boundaries of "DNS abuse" end, which actors in the DNS ecosystem are responsible for responding, and how to intervene without causing disproportionate damage to legitimate users.

The ICANN definition#

ICANN, the organization that coordinates the global domain name system, formally defines DNS abuse as five categories:

  1. Malware. Malicious software distributed through or controlled via domain names
  2. Botnets. Networks of compromised devices coordinated through DNS-based command and control
  3. Phishing. Fraudulent sites that harvest credentials or sensitive information, typically hosted on lookalike domains
  4. Pharming. Redirecting users to fraudulent sites through DNS hijacking or cache poisoning
  5. Spam. But only when spam serves as a delivery mechanism for one of the four categories above

This definition was codified in April 2024 through amendments to the Registrar Accreditation Agreement (RAA) and the Base gTLD Registry Agreement, creating binding contractual obligations for registrars and registries to act when presented with actionable evidence of DNS abuse. Before 2024, these obligations existed primarily as voluntary best practices.

Why the definition is narrow, and why that's intentional#

A broader definition of DNS abuse would give registrars and registries wider authority to suspend domains. That authority comes with serious risks:

  • Free expression. Expanding DNS abuse to include "harmful content" would put registrars in the position of content moderators, a role they are neither equipped for nor mandated to perform
  • Jurisdictional conflict. What constitutes illegal content varies by country. A domain legal in one jurisdiction may violate laws in another. Registrars operate globally and cannot adjudicate between legal systems
  • Collateral damage. Suspending a domain removes everything associated with it (the website, email, APIs, subdomains). This is appropriate for a domain registered solely for fraud, but devastating if applied to a legitimate business domain that was briefly compromised

The narrow definition keeps the scope of registrar/registry action focused on cases where there is broad consensus that the DNS itself is being weaponized, and where DNS-level intervention is both effective and proportionate.

Critics argue the definition is too narrow, that it allows registrars to avoid action on clearly harmful activity that doesn't fit neatly into five boxes. Supporters argue that any expansion risks mission creep into content regulation, which is outside ICANN's remit and better handled by hosting providers, platforms, and courts.

Abuse of the DNS vs. abuse through the DNS#

One of the most important distinctions in DNS abuse, and one that the ICANN framework now explicitly recognizes, is whether the DNS is being attacked or merely used as infrastructure:

  • Abuse of the DNS means the DNS infrastructure itself is the target or the mechanism of attack:

    • DNS cache poisoning, injecting forged responses into resolver caches
    • DNS hijacking, compromising registrar accounts or name server configurations to redirect traffic
    • DNS tunneling, encoding data in DNS queries to exfiltrate information or establish covert command-and-control (C2) channels
    • Domain generation algorithms (DGAs), malware that algorithmically generates hundreds of thousands of domain names for botnet command-and-control (C2) traffic, requiring only a few to be registered on any given day
  • Abuse through the DNS means harmful content or activity uses domain names as part of its delivery, but the DNS infrastructure itself is not being attacked:

The distinction matters because different actors are best positioned to respond to each type. DNS protocol attacks may require resolver operators or software vendors to act. Maliciously registered domains call for registrar or registry intervention. And compromised legitimate websites need the hosting provider or site owner to remediate, not a domain takedown.

Malicious registration vs. compromised domains#

This is perhaps the most operationally critical distinction in DNS abuse, and one that automated blocklists frequently fail to make:

  • Maliciously registered domains were created solely for abuse, the registrant is the attacker, and the domain has no legitimate purpose. Suspending or deleting these domains causes no collateral damage and is the appropriate response. Registrars are the right actor.

  • Compromised domains are legitimate domains whose websites or DNS configurations have been hijacked. The domain owner is a victim, not a perpetrator. Suspending the domain punishes the victim, potentially taking their business offline. The appropriate response is to notify the domain owner and/or hosting provider so the compromise can be remediated at its source.

The challenge is that distinguishing between the two requires investigation, checking domain age, registration history, WHOIS/RDAP data, DNS history, and web content. Automated systems can approximate this classification (for example, a domain registered two hours ago distributing malware is almost certainly malicious), but edge cases require human judgment.

The registrar obligations since April 2024#

The 2024 contract amendments transformed DNS abuse mitigation from best practice to contractual requirement. Key provisions:

  • Registrars must maintain accessible abuse reporting mechanisms, ensure reports are processed, and, when presented with actionable evidence of DNS abuse, "promptly take the appropriate mitigation action(s) reasonably necessary" to stop or disrupt the abuse
  • Registry operators have parallel obligations and may be the appropriate actor for large-scale abuse (e.g., DGA-based botnets spanning multiple registrars within a single TLD)
  • Both must exercise reasonable discretion in selecting mitigation actions. The framework explicitly acknowledges that the right response depends on the circumstances of each case
  • ICANN Contractual Compliance enforces these obligations and has issued breach notices, conducted targeted audits, and required remediation plans from non-compliant registrars

These obligations apply only to gTLDs. Country-code TLDs (ccTLDs) operate under their own national frameworks and are not bound by ICANN's RAA or Registry Agreement.

The reporting problem#

Even with clear obligations, the mechanics of reporting DNS abuse remain fragmented:

  • There is no universal standard for abuse report format. Different registrars accept reports through different channels (web forms, email, APIs) with different evidence requirements
  • WHOIS privacy and GDPR redaction make it difficult to identify the responsible registrar or contact the domain owner
  • Abuse reports submitted by automated systems are often duplicative, unevidenced, or directed to the wrong party
  • Registrar spam filters sometimes block legitimate abuse reports, particularly those containing malicious domain names, which the filter flags as suspicious content

The scale of the problem#

DNS abuse intersects with broader cybercrime economics. Domain registration is cheap (on the order of ten dollars per year for many TLDs), bulk registration APIs allow hundreds of domains to be acquired in minutes, and privacy-protected registration obscures the registrant's identity. This creates an asymmetry where attackers can generate infrastructure faster than defenders can take it down.

Typosquatting and business email compromise illustrate how this asymmetry plays out in practice. Any organization with a recognizable brand has hundreds or thousands of plausible lookalike domains, character swaps, added words, alternative TLDs, that an attacker can register for a few dollars each. A single convincing lookalike with a working mail server is enough to send a BEC email that tricks an employee into wiring funds or handing over credentials. The FBI consistently ranks BEC among the costliest categories of cybercrime, with annual losses in the billions. Defenders must monitor every plausible permutation of their brand; attackers need only one registration to go unnoticed.

How DNS abuse connects to domain monitoring#

For organizations concerned about their own domains being abused, through typosquatting, brand impersonation, or lookalike domain registration, DNS abuse is the threat model, and domain monitoring is the detection layer.

Domain protection platforms like Have I Been Squatted generate thousands of permutations of your domain, monitor for new registrations, check Certificate Transparency logs for suspicious certificates, and enrich each match with DNS, hosting, and content signals. When a maliciously registered lookalike domain is confirmed, the ICANN framework provides the contractual basis to request mitigation from the registrar, a process that now carries enforceable obligations rather than relying on goodwill alone.

Understanding the DNS abuse landscape, who is responsible, what constitutes actionable evidence, and which mitigation actions are appropriate, is essential context for any DNS security program and any brand protection program that depends on domain takedowns as part of its enforcement strategy.

More from DNS security

View all

Put what you learn into practice

Monitor typosquats, investigate infrastructure, and move from reading to detection with continuous domain coverage built for security teams.