I Found 2,209 Domains Delegated to Misspelled Name Servers — Here's How the Attack Works

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 I found 2,209 live examples of it across 240.3 million domains.

For the full table of detected typosquats and affected domains, see the typosquatted NS dashboard, which updates daily. This article explains how the attack works, how I detect 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 240 million domains required a pipeline that generates plausible typos for known NS hostnames and checks whether those typos actually appear in zone file data.

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

Step 2: Generate typo candidates. For each reference hostname's domain component, I applied 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 generated roughly 120,000 candidate typos.

Step 3: Match against zone file data. I checked each candidate 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: Manual review. I eliminated false positives — legitimate providers whose names happen to be similar to other providers. The final dataset: 258 confirmed typosquatted hostnames affecting 2,209 domains across 42 targeted providers.

The Anatomy of an NS Typosquat Attack

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

Target: hostineer.com (492 domains)

hostineer.com is a misspelling of hostinger.com — one of the world's largest web hosting providers. The typo drops the 'g' from "hostinger," a plausible error since 'g' and 'e' are adjacent on QWERTY keyboards.

492 domains in the zone file data have NS records pointing to ns1.hostineer.com or ns2.hostineer.com. These domain owners intended to point to Hostinger's name servers but mistyped the hostname.

The attack:

1. The attacker checks if hostineer.com is registered. If not, they register it for ~$10.
2. They configure A records for ns1.hostineer.com and ns2.hostineer.com pointing to their server.
3. They install DNS server software (BIND, PowerDNS, CoreDNS) and configure it to serve authoritative responses for the 492 delegating domains.
4. DNS resolvers worldwide start querying the attacker's server for those 492 domains — and getting authoritative responses.
5. For high-value targets among the 492, 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 492 domains.

Target: wixdns.ne (380 domains)

This one surprised me. It's not a character-level misspelling — it's a TLD truncation. The legitimate hostname is wixdns.net, but 380 domains point to wixdns.ne — the .ne ccTLD for Niger.

This means registering wixdns.ne in Niger's ccTLD registry gives the attacker control over 380 domains. Niger's .ne TLD has open registration with no special requirements.

The truncation pattern likely happens during copy-paste: the domain owner selects the NS hostname but misses the final character. The registrar accepts it because wixdns.ne is syntactically valid. The domain owner never notices because the failure is silent — the domain just doesn't resolve.

Target: cloudfare.com (166 domains)

The cloudfare.com typo (missing the 'l' from cloudflare.com) is arguably the most well-known NS typosquat. Cloudflare has actually addressed this specific case — cloudfare.com has been registered defensively. But the data still shows 166 domains with NS records pointing to it, indicating that either the defensive registration happened after these delegations were created, or these domains were delegated before Cloudflare's defensive action.

This case illustrates both the problem (166 domains at risk from a single typo) and a partial solution (defensive registration by the targeted provider).

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 Mismatch

2,209 affected domains is a tiny fraction of 240 million — barely 0.001%. This scale mismatch works against fixing the problem. Registrars see it as a rounding error. ICANN doesn't see it as systemic. Security conferences focus on larger-scale vulnerabilities.

But 2,209 domains is 2,209 businesses or organizations whose DNS could be silently hijacked with a domain registration. And that's just what I can detect from zone file data — the real number is likely higher, since some typosquatted NS domains may already be registered (either defensively or maliciously) and thus serve responses that make the delegation appear functional.

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.