devansh

Fragility of The Internet: How Sacrificial Nameservers allowed potential DNS hijacking of 1.6+ million domains

bersek

Table of Contents

Preface

DNS is a fundamental yet intricate system, serving as the backbone of the internet. The entire online ecosystem relies on it, making its integrity crucial. Since deep diving into DNS research, I have found it increasingly unsettling—perhaps you will too after reading this.

When we type google.com into the browser’s address bar, we expect to be directed to Google’s official landing page. In most cases, this expectation holds true—unless the site is down or deliberately redirects elsewhere. But imagine a scenario where you arrive at a page hosted under google.com, yet it isn’t controlled by Google—instead, it's a phishing site. While highly improbable, such an attack could become a reality if a malicious actor were to manipulate google.com’s DNS records or gain control over its hosted content.

In this piece of writing, we will explore various components of the DNS ecosystem, including the root zone, authoritative name servers, registrars, registries, EPP, and How Sacrificial Nameservers allowed possible DNS hijacking of 1.6+ million domains. But before diving into these topics, let’s begin with this…

A primer on DNS resolution process and the role of nameservers

The Domain Name System (DNS) acts as the internet's address book. It translates human-readable domain names (e.g., example.com) into IP addresses (e.g., 192.168.1.1). Without DNS, we would have to remember long numerical IP addresses for every website.

When you type example.com into your browser, here's what happens (on a higher level):

Key Players in DNS

1. Registry

2. Registrar

3. Registrant

4. Nameservers

Common DNS Records

Record Type Purpose
A Record Maps a domain to an IPv4 address
AAAA Record Maps a domain to an IPv6 address
CNAME Alias for another domain (e.g., www.example.com → example.com)
MX Record Mail server configuration (for email routing)
TXT Record Miscellaneous text-based data (e.g., SPF, DKIM, verification)
NS Record Defines the authoritative nameservers for a domain

A case of unusual DNS hijacking

I love doing automation, reconnaissance, and conducting internet-scale scanning of digital assets (domain names, IPv4 space) for various purposes. As part of this automation process, I was scanning domains within the scope of a bug bounty program that returned a SERVFAIL response. The goal was to identify potential DNS zone hijacking issues.

Before long, my automation flagged a domain that was returning a SERVFAIL error during the DNS resolution process. Interestingly, it also had two associated nameservers that were available for purchase.

Note: I have changed the name of the vulnerable domain and it’s NS for anonymity of the affected organization

The nameservers appeared somewhat unusual, following the pattern dropthishost-UUID-randomstring.biz. However, at the time, I didn’t dive deeper into investigating their origin.

Since these nameservers were available for purchase, an attacker could have taken control of redactedxyz.com, redirected its traffic, created arbitrary subdomains under *.redactedxyz.com, and exploited the domain in various ways.

I reported this issue to the affected organization, which acknowledged its severity, awarded a €3,000 bounty and I moved on. [We will revisit this case shortly.]

Unusual patterns and lots of SERVFAIL

I love hacking things (ethically), and one of its most important aspects is the ability to integrate different tools and techniques to develop solutions that address specific problems or improve your efficiency. As part of this integration process, I began incorporating LLMs into my automation workflow.

I utilize LLMs to identify patterns within my scanning results, allowing me to query indexed and vectorized data using natural language. For instance, I can input a query such as, “Retrieve all domains that returned a NOERROR response but have no associated IP address” and obtain precise results. This is just one example—I frequently use LLMs to detect anomalous patterns and occasionally backtrack, leveraging them to generate queries dynamically.

Furthermore, I can train my model on publicly available DNS related bug reports and instruct the LLM to generate pattern-based queries. These queries can then be executed against my DNS scanning dataset, enabling the identification of potential security issues or misconfigurations. The LLM generated and executed a query against the scanned dataset with the following condition:

“Retrieve all domains that returned a SERVFAIL response but have nameservers that do not resolve and return an NXDOMAIN status code.”

This query was designed to identify domains with misconfigured or orphaned nameservers. However, the results were both surprising and confusing—I obtained thousands of domain names as output. Amidst the vast dataset, one particular pattern stood out to me.

Upon closer examination, the pattern of these nameservers—dropthishost-UUID-randomstring.biz—seemed eerily familiar. It was identical to the one observed in the DNS hijacking case of redactedxyz.com. Just like in that instance, these nameservers were also available for purchase.

At this point, several questions were cooking up in my mind:

  1. Where are these unusual nameservers originating from?

  2. Who assigned these nameservers to these domain names?

  3. What purpose do these nameservers serve?

  4. Since these nameservers are available for purchase, does this mean that anyone can hijack the domains associated with them? This seemed like a serious security issue.

Determined to find answers, I grabbed a cup of coffee and began my investigation. To start, I performed a dig +trace on one of the affected domains.

This confirms that these dropthishost-UUID-randomstring.biz NS are indeed authoritative NS for the affected domain. When checking the NS apex domain on a domain registar is available for registartion.

But why would someone intentionally change the nameservers of their domain to ones that are available for purchase? This seemed completely irrational—almost absurd—especially considering the sheer scale of the issue. With thousands of domains affected, this was clearly not an isolated incident.

At this point, it became evident that this wasn’t a simple case of human error. Instead, it pointed toward a systemic or mechanical issue, potentially caused by an automated process, misconfiguration, or an underlying flaw in DNS infrastructure.

I needed answers—and I needed them fast. The sheer scale of the issue was unsettling, and I couldn’t shake the feeling that something deeper was at play. Determined to get to the bottom of it, I started reading RFCs, tracing the evolution of DNS from its inception to the most recent DNS-related specifications.

As I dived into these documents, I found several interesting and quirky behaviors within the DNS ecosystem. More importantly, I almost found answers to all the critical questions I had raised earlier.

The Answer is in The RFC 5731

RFC 5731, titled "Extensible Provisioning Protocol (EPP) Domain Name Mapping", is a specification that defines how domain names are managed using the Extensible Provisioning Protocol (EPP).

It defines the EPP mapping for domain name management, and allows domain registrars to create, update, delete, and query domain names in a registry. Simply put, EPP acts as a bridge between registrars and registries.

Section 3.2.2 of the RFC has details about EPP <delete> Command. The following excerpt of that section caught my attention:

Suppose you own example.com, and it has two nameservers: ns1.example.com and ns2.example.com.

If the registrar tries to delete example.com via EPP, the request will fail with a 2305 error. This happens because the domain still has dependent records (the nameservers). To successfully delete example.com, the registrar must first remove or rename ns1.example.com and ns2.example.com. Once these are deleted, the request will go through, and example.com will be removed.

But what if another domain, example-another.com, registered with a different registrar, also has its nameservers set to ns1.example.com and ns2.example.com? As previously mentioned, the nameservers for example.com must either be renamed or deleted before example.com itself can be removed. However, since example-another.com is managed by a different registrar, the registrar of example.com cannot directly delete or update its nameserver (NS) records.

As per RFC 5731, Registrar A (which controls example.com) can rename the host object ns2.example.com to a different domain that Registrar A also controls, ensuring it is no longer subordinate to example.com.

For example, some registrars have previously renamed unwanted nameservers to {randomstring}.dummyns.com, where dummyns.com was a "sink" domain operated explicitly for this purpose. This approach mitigates hijacking risks, but it requires careful management to ensure dummyns.com itself is not hijacked.

Another common approach is renaming each unwanted host object to an entirely new, non-existent domain. While this minimizes the registrar’s maintenance burden, it introduces a potential risk of future hijacking. However, this method presents a new challenge:

In an EPP (Extensible Provisioning Protocol) repository, it is not possible to create a dangling domain reference. Specifically, EPP will not allow a host object to be renamed to a non-existent domain within its own namespace.

For example, in Verisign’s EPP instance, one cannot create ns2.foobar.com unless foobar.com already exists.

Exploiting an EPP Loophole

Some registrars have identified a loophole in EPP behavior. EPP enforces strict validation only within its own namespace. However, if the new superordinate domain is in a different TLD (Top-Level Domain), such as .biz, the EPP instance does not enforce the same restrictions.

This means that Verisign’s EPP instance will allow renaming ns2.example.com to ns2.example-random.biz, even though example-random.biz does not exist.

As a result:

Source: https://www.caida.org/catalog/papers/2021_risky_bizness/risky_bizness.pdf

This unintuitive and unintended behavior effectively orphaned thousands of domain names, making them vulnerable to hijacking. This is why we were seeing dropthishost-UUID-randomstring.biz set as NS for thousands of domain names, as these are sacrificial namesevers.

While researching about this, I came across this awesome research paper title “Risky BIZness: Risks Derived from Registrar Name Management“ and it gave all the answers I was looking for. The researcher paper mentions the risks stemming from the use of third-party nameservers when the nameserver domain is slated for removal by its registrar. When registrars cannot delete expired domains with dependents, they sometimes rename unwanted nameserver host objects to unregistered domains. If a domain had delegated its nameservice to a specific domain, the nameserver might be silently replaced. The study found that this practice has put at least half a million domains at risk of hijacking in the past.

The research paper also highlights an intriguing case where a human error inadvertently put over 1.6 million domain names at risk of DNS hijacking.

Potential DNS Hijacking of 1.6+ million domain names

The historical NS record analysis for tiktok.com reveals an unusual and concerning event from July 26th, 2016, when a set of anomalous nameservers were added. A reverse historical NS search on these nameservers confirms that they were previously attached to over 1.6 million domains—a massive-scale incident.

The research paper Risky BIZness: Risks Derived from Registrar Name Management provides a detailed explanation for this mystery.

What Happened?

In July 2016, Namecheap mistakenly sent a deletion request for registrar-servers.com (their default nameserver domain) to Enom, which was handling domain registrations for them at the time. However, Enom could not process the deletion while subordinate nameservers like ns1.registrar-servers.com still existed.

To circumvent this restriction, Enom’s automated deletion system renamed 46 default Namecheap nameservers to .biz TLDs, following the common "rename-to-delete" practice. This unexpected change resulted in 1.6 million domains—including high-profile ones like TikTok.com—being left with dangling delegations, making them vulnerable to domain hijacking.

Conclusion

The primary technical discovery is an unforeseen interaction between registrar practices and registry provisioning constraints, leading to at least thousands of domains being vulnerable to hijacking. The research paper Risky BIZness: Risks Derived from Registrar Name Management already described some common patterns for the sacrificial nameservers being used. But are there more NS patterns which are still not documented anywhere? Yes! Stay tuned for the next piece of writing on this ;)

References