Skip to main content
DNS Checker(beta)
Updated 9 min read

145,061 Domains Delegated to a Misspelled Name Server — Here's How the Attack Works

Ishan Karunaratne

Ishan Karunaratne

Software Architect & Infrastructure Engineer

Every domain on the internet delegates its DNS to name servers specified by hostname — like ns1.cloudflare.com or dns1.hostinger.com. These hostnames are typed into registrar control panels by humans, and humans make typos. When a domain owner types ns1.cloudfare.com (missing the 'l') instead of ns1.cloudflare.com, their domain silently delegates its entire DNS to whoever controls cloudfare.com.

This isn't a bug in the DNS protocol. It's a gap in the registrar ecosystem: most registrars accept any syntactically valid hostname as a name server without checking whether it's real, responsive, or suspiciously similar to a known provider. The result is a class of vulnerability I call NS typosquatting — and the detection pipeline I built scans 260 million domains daily for exactly this.

The current headline finding: 145,061 domains are delegated to domainnamens.com — a misspelling of ResellerClub's domainnamedns.com. A single missing 'd' has left 145,061 domains exposed to silent DNS hijacking.

For the full table of detected typosquats and affected domains, see the typosquatted NS dashboard, which updates daily from zone file data. This article explains how the attack works, how the detection pipeline identifies it, and why it's harder to fix than it should be.

Why NS Typosquatting Is Different from Regular Typosquatting

Regular typosquatting is a well-known attack: register gooogle.com and wait for people to mistype google.com in their browser. The attacker gets visitors who make a specific mistake at a specific moment.

NS typosquatting is fundamentally different in three ways:

It's passive. The victims don't make a mistake in their browser — they made a mistake once, when configuring their domain's NS records, possibly years ago. Every DNS query for their domain goes to the typosquatted server automatically.

It's total control. Regular typosquatting gives you an HTTP connection from visitors. NS typosquatting gives you authoritative DNS control — A records, MX records, TXT records, everything. You can redirect web traffic, intercept email, and issue TLS certificates.

It's invisible. When you typosquat a website URL, the visitor sees the wrong page and may notice. When a domain's NS records point to a typosquatted hostname, the domain owner usually thinks their domain "just doesn't work" and troubleshoots at the hosting level. They rarely check their NS records for a character-level typo.

How I Built the Detection Pipeline

Finding typosquatted name servers across 260 million domains requires a pipeline that generates plausible typos for known NS hostnames and checks whether those typos actually appear in zone file data. The pipeline runs daily against fresh zone files from 1,107 gTLD zones.

Step 1: Build the reference set. I extract every unique NS hostname from the zone files and identify those serving more than 1,000 domains — the established providers. This gives approximately 2,400 reference hostnames belonging to roughly 800 providers.

Step 2: Generate typo candidates. For each reference hostname's domain component, I apply five typo generation strategies:

  • Character deletion: Remove each character → cloudflare becomes cloudfare, cloudlare, cloudflar, etc.
  • Character insertion: Double each character → hostinger becomes hhostinger, hoostinger, hostingerr, etc.
  • Character substitution: Replace with QWERTY-adjacent keys → hetzner becomes hetznar, hetznwr, getzner, etc.
  • Character transposition: Swap adjacent characters → cloudflare becomes cloudlfare, cloadflare, etc.
  • TLD truncation: Remove the last character of the TLD → .net becomes .ne, .com becomes .co

This generates roughly 120,000 candidate typos.

Step 3: Match against zone file data. Each candidate is checked against the actual NS hostnames found in zone files. A match means a real domain has been delegated to a name server hostname that is within one edit of a known provider.

Step 4: False-positive filtering. Edit-distance matching produces many coincidental hits — SAP AG (sap.com) is edit-distance 1 from Sav Marketplace (sav.com), but SAP is obviously not a typosquat. The pipeline applies three layers of filtering:

  • Explicit exclusion list: Audited false positives — known companies, providers' own defensive registrations, and legitimate services whose names happen to be similar (10 entries covering SAP, SAS Institute, MarkMonitor, Neustar/UltraDNS, HostGator .co, Hostinger .co, and others).
  • Minimum name length: Domains with base names under 5 characters generate too many coincidental matches (this alone filters ~1,200 pairs).
  • Provider-is-provider check: If the flagged domain is itself a known DNS provider, the match is coincidental, not a typosquat.

After filtering, the pipeline currently identifies 1 confirmed high-confidence typosquat affecting 145,061 domains.

The Anatomy of an NS Typosquat Attack

Let me walk through exactly how an attacker would exploit this, using a real example from the current data.

Target: domainnamens.com (145,061 domains)

This is the largest confirmed NS typosquat in the dataset. domainnamens.com is a misspelling of domainnamedns.com — the NS hostname used by ResellerClub (Endurance International Group), one of the largest white-label hosting providers. The typo drops the 'd' from "domainnamedns," a plausible error since the string "namedns" could easily be read as "namens."

145,061 domains in the zone file data have NS records pointing to hostnames under domainnamens.com. That is 0.056% of all gTLD domains, exposed by a single missing character.

The attack:

  1. The attacker checks if domainnamens.com is registered. If not, they register it for ~$10.
  2. They configure A records for ns1.domainnamens.com and ns2.domainnamens.com pointing to their server.
  3. They install DNS server software (BIND, PowerDNS, CoreDNS) and configure it to serve authoritative responses for the 145,061 delegating domains.
  4. DNS resolvers worldwide start querying the attacker's server for those domains — and getting authoritative responses.
  5. For high-value targets among the 145,061, the attacker sets up phishing pages, intercepts email, or issues TLS certificates.

Total cost: $10 for the domain + a VPS. Total yield: authoritative DNS control over 145,061 domains.

Note: domainnamens.com is currently registered (since March 2025) and its NS records point to domainnamedns.com — the legitimate provider's servers. This could be a defensive registration by ResellerClub or the same corporate parent. But the 145,061 domains delegating to it demonstrate the scale of what a single-character NS typo can produce.

TLD Truncation: The Copy-Paste Attack

One of the most dangerous typo categories isn't a character misspelling — it's a TLD truncation. When a domain owner copies ns1.hostgator.com but misses the final character, they get ns1.hostgator.co — and .co (Colombia) is a valid, openly-registrable TLD that looks almost identical to .com.

This pattern also occurs with .net.ne (Niger) and .org.or (not a valid TLD, but attempted). TLD truncations are especially dangerous because the resulting hostname looks correct at a glance — the domain owner may not notice the difference between .com and .co when reviewing their NS configuration.

Defensive Registration: cloudfare.com

The cloudfare.com typo (missing the 'l' from cloudflare.com) is arguably the most well-known NS typosquat. Cloudflare has addressed this specific case — cloudfare.com has been registered defensively. Domains with NS records pointing to it get Cloudflare's error page rather than an attacker's server.

This illustrates both the problem (hundreds of domains at risk from a single common typo) and the most effective solution: providers proactively registering obvious misspellings of their NS hostnames.

What Makes This Harder to Fix Than It Should Be

The Registrar Validation Gap

I tested 12 major registrars by attempting to set NS records to obviously invalid hostnames. The results:

  • All 12 accepted syntactically valid but non-resolving hostnames
  • 9 of 12 accepted hostnames with no DNS server running
  • 0 of 12 performed typosquat detection against known providers

This means any domain owner can accidentally delegate to a typosquatted hostname, and the registrar will propagate it to the TLD zone without question. The validation gap exists because:

  1. NS records can be "forward-looking" — you might set NS records before the name server is configured, so non-resolution isn't necessarily an error
  2. No canonical list of "valid" name servers exists — anyone can run a DNS server on any hostname
  3. Registrars optimize for simplicity — adding validation steps to NS configuration creates friction in a competitive market

The Scale Problem

145,061 affected domains is 0.056% of 260 million — a small fraction. But the impact isn't distributed: a single typosquat (domainnamens.com) accounts for all of them. Someone who registers that one domain gets authoritative DNS control over 145,061 organizations. The cost-to-impact ratio is staggering: a $10 domain registration could yield control over tens of thousands of DNS zones.

And this is only what the pipeline can detect from gTLD zone file data — ccTLD zones (which aren't publicly available) likely contain their own NS typosquats. Many additional typosquatted NS domains may already be registered (either defensively or maliciously), making the delegation appear functional and thus invisible to zone-file-based detection.

Defensive Strategies

For DNS Providers (Most Impactful)

The most effective defense is for DNS providers to register common typosquats of their NS hostnames defensively. Cloudflare's registration of cloudfare.com is the right model. Every major DNS provider should:

  1. Generate all single-edit-distance typos of their NS domain
  2. Generate TLD truncations (.net.ne, .com.co)
  3. Register the ones that are available
  4. Point them to a landing page explaining the error

This is a one-time cost of a few hundred dollars per provider and permanently eliminates the most exploitable typosquats.

For Registrars (Systemic Fix)

Registrars should implement a lightweight NS validation step:

  1. When a domain owner submits NS records, check the submitted hostname against a list of known DNS providers (available via public NS hostname databases)
  2. If the submission is within edit distance 1-2 of a known provider but doesn't match exactly, show a warning: "Did you mean ns1.cloudflare.com?"
  3. Allow the user to proceed if they confirm, but the warning catches 90% of typos

This doesn't require blocking any NS records — just a suggestion dialog. It would eliminate most NS typosquats without adding friction for legitimate configurations.

For Domain Owners (Immediate)

  • Verify your NS records using the DNS Inspector. Compare every character against your provider's official documentation.
  • Always copy-paste NS hostnames from your provider's setup page. Never type them from memory.
  • Set up external DNS monitoring that alerts when your domain stops resolving. This catches typosquatted NS records that fail silently.

The typosquatted NS dashboard lists all detected typosquats with their intended providers and affected domain counts.


Frequently Asked Questions

This article was researched and structured by the author with AI assistance for drafting and technical verification.

About the Author

Ishan Karunaratne
Ishan Karunaratne

Software Architect & Infrastructure Engineer

US Army veteran with a B.S. in Information Technology, CompTIA A+, Network+, and Security+ certified. 20+ years building and securing web infrastructure.

B.S. Information Technology — Online SystemsCompTIA A+ (2009)CompTIA Network+ (2009)CompTIA Security+ (2009)US Army Veteran — Operation Iraqi Freedom

Share this article

Related Articles

What Happens When One DNS Provider Goes Down: The Hidden Fragility of TLD Ecosystems

The Dyn attack took down Twitter and Netflix because they shared a DNS provider. I analyzed 240 million domains and found 112 TLDs where a single provider controls over half the domains. The next Dyn-scale event isn't a question of if, but which TLD.

How Expired Name Servers Become Domain Hijacking Vectors

When a name server domain expires, every domain that still delegates to it becomes vulnerable to hijacking. I found 503,000 domains pointing to expired NS domains — and a single re-registration could compromise hundreds of thousands of them.

Why DNSSEC Is Still Failing: Lessons from 240 Million Domains

After 20 years, only 4.27% of domains have DNSSEC. I analyzed 240 million domains to understand why — the answer isn't technical, it's structural. Registrar defaults, invisible benefits, and operational fear are holding back the one protocol that could fix DNS authentication.

Complete Guide to DNS Attacks and DNS Security (Prevention, Testing & Mitigation)

A comprehensive guide to DNS attack types including cache poisoning, amplification, tunneling, zone walking, and hijacking. Learn how attackers exploit DNS, how to test your own domains, and how to harden your infrastructure.