DNS Abuse is any malicious activity aimed at disrupting the DNS infrastructure or causing the DNS to operate in an unintended manner. It is different from bad practices. Abusive activities include corrupting DNS zone data, gaining administrative control of a name server, and flooding the DNS with thousands of messages to degrade name-resolution services.[1]

Abuse of the DNS: Traffic that causes DNS servers or intermediate architecture involved in the transmission or processing of DNS services, or both, to be degraded or unavailable to third parties, or that causes unintended results in the service provided by DNS service operators or registry service providers.

Abuse via the DNS: Harmful cyber activity that cannot take place without using the DNS, but where the threat actors' operations do not constitute abuse of the DNS.[2]

Related Articles edit

  • See here for an overview of various stakeholders' opinions of and reactions to DNS Abuse.
  • See here for the closely related but much broader topic of cybercrime.

Overview edit

Definitions of DNS abuse can refer to the abuse of the protocol or the infrastructure or using DNS services or domain names to carry out other forms of abuse[3]. Manual mistakes, escalation of privileges, and compromised account access are all hallmarks of most breaches or attacks.[4]

According to the Internet and Jurisdiction Policy Network, there are five broad categories of DNS abuse:[5]

  • malware, such as ransomware,
  • Botnet Attacks,
  • phishing,*(FIRST DNS Abuse SIG argues phishing that does not rely on the DNS is not DNS Abuse; e.g., it may be content abuse or it may occur via an unregistered domain)[6]
  • pharming, and
  • spam (when it is used to deliver other forms of DNS Abuse), accounting for over 85% of DAAR-reported DNS abuse in February 2021.[7]

A broader set of DNS security threats include:

DNS abuse adjacent issues edit

Vectors edit

The DSFI-TSG identified seven categories of attack vectors.[10]

Identity and Access Management edit

  • Attacks on and through credential systems result in the modification of registration data, which can lead to Domain Hijacking, traffic interception, and social engineering attacks.
  • when a registrant’s credentials are compromised, the attacker can impersonate the registrant to
    1. Transfer the domain out of the registrant’s control,
    2. Modify the DNS servers to intercept traffic or redirect it to a criminal destination,
    3. Modify the Authoritative DNS Servers allowing attackers to monitor, alter or deny queries and redirect end users to malicious endpoints,
    4. Modify DNSSEC-related data by removing the DS records,
    5. Modify authoritative records of the domain name, domain registration, or DNS service, or
    6. Delete or de-register the domain.

Access Control and Authorization edit

  • Bad actors can gain access to unauthorized services and/or data. In the case of a subdomain takeover, non-authorized users gain access to publish content under a DNS label that they have not been authorized to control.

Resource Impersonation edit

  • A bad actor can impersonate a recursive resolver by intercepting traffic to it at the network layer after changing the user's configuration.
  • When illegitimate server operators receive DNS queries for an authoritative nameserver, they can return incorrect response data, make it so only certain geographic areas see altered data, and populate a recursive cache with incorrect results.[11]
  • Using look-alike domains relies on similarities in domain names, such as Domain suffix appending, Typosquatting, or internationalized domain name homographs, or bitsquatting to lead users into interacting with a bogus website, generally to carry out a phishing attack.
  • Transport Layer Security (TLS) certificates can be issued to a requestor who is not the legitimate operator of the service secured by the certificate when there are inadequate access controls of DNS entries or the BGP route has been manipulated.

Code and Protocol Vulnerabilities edit

Infrastructure Choices edit

DNS edit

Denial of Service edit

History edit

In 2009-2010, the Registration Abuse Prevention Working Group (RAPWG) generated a report that distinguished between “Registration Abuse” (technical abuse) and “Use Abuse” (content abuse). Technical abuse was defined as attempts to harm the DNS infrastructure and/or using the DNS to cause harm. Content abuse was defined as harms carried out through the use of a domain name, such as through the content on a website. This category of harm includes trademark and copyright infringement, defamation, piracy, child sexual abuse, and hate speech. The RAPWG concluded that technical abuse was within ICANN’s jurisdiction but content abuse was not. However, the working group recommended the development of the Uniform Dispute Resolution Policy (UDRP) because it involved the registration and use of domain names in bad faith.[12]

In 2013, conversations between the Governmental Advisory Committee and the ICANN Board led to an amendment to Registry Agreements in 2013 to include Specification 11. Registry operators must now periodically conduct a technical analysis to assess whether domains within their TLD are used to carry out security threats, such as pharming, phishing, malware, and botnets. They must also include terms in their RRAS such that registrants are prohibited from perpetuating technical and content abuse.

In 2016, when the ICANN Bylaws were re-written as part of the IANA Transition, a provision was added to state that ICANN is not responsible for content.

In 2019, a group of domain name registries and registrars developed and released a document called the "Framework to Address Abuse," with 11 signatories.[13] By 2021, 48 signatory registrars and registries had voluntarily bound themselves by the principles laid out in the framework.[14]

Open Questions edit

Defining and Measuring the Problem edit

Is there a hard and fast difference between technical abuse and content abuse?

  • The BC and GAC want more enforcement from ICANN in terms of gray areas, for instance, when technical and content abuse overlap[15]
  • The ICANN Board does not want to deliberate over content issues

How should DNS abuse be measured?

  1. Domain Abuse Activity Reporting (DAAR) - ICANN releases a monthly report on malicious activity
  2. SURBL
  3. Spamhaus
  4. PhishTank
  5. .ORG Anti-Abuse Metrics

Responsibility edit

Remit: Whose job is it to stop the abuse?

  • Registries do not host content and therefore cannot remove a piece of content from a website. The only way to remove content from the Internet is to delete it from the computer that hosts it via the hosting provider, or permanently remove that device from the Internet.

Interoperability: Can the various stakeholders work together to combat attacks?

Mitigation edit

  1. being more timely (immediately posted and immediately taken down) and
  2. distinguishing between Compromised Domains and Malicious Domains?
  • Is there too much focus on Authoritative DNS and not enough on the entire DNS ecosystem?
  • How to reduce gap/time lag between policy and incident response?[16]

Intersecting Issues edit

Jurisdictional confusion

Law enforcement wants more cooperation from industry leaders

Data privacy and limits imposed by the General Data Protection Regulation

Progress edit

Is it getting better or worse?

Getting worse: In March 2021, the FBI’s Internet Crime Complaint Center (IC3) released its 2020 Internet Crime Report. There were 791,790 complaints of suspected internet crime, which indicated an increase of more than 300,000 from 2019, involving losses in excess of US$4.2 billion. Phishing, non-payment/non-delivery scams, and extortion were the top three types of crime reported.[17]
Getting better:

Are new or Legacy gTLDs experiencing more problems? The February 2021 DAAR report indicates the majority (64.8%) of security issues are occurring in legacy TLDs, which comprise 88.8% of resolving gTLD domains in zone files.[18]

References edit