A phishing report lands in your queue: secure-examplebank-login.com. You block it, file a takedown, and close the ticket. You may have dealt with one domain out of forty.

Most domain monitoring starts with names. We watch new registrations for our brand, check the TLDs we care about, and flag anything that looks close. That work is necessary, but it only covers what the attacker chose to call things. Attackers know this, and they work around it.

Every domain has three parts worth watching. Defenders look at the first two: the name (examplebank) and the TLD (.com). The third gets far less attention, and it is the one attackers find hardest to change: the nameserver.

Attackers Register in Batches

Phishing and fraud operators rarely register one domain at a time. They register sets: brandlogin.com, brand-support.net, a few lookalikes on cheap new gTLDs, and often random strings like xk29fj.xyz with no brand in them at all.

The research shows how industrial this has become. Interisle Consulting Group’s Phishing Landscape 2025, covering May 2024 to April 2025, found that 77% of domain names reported for phishing were registered by the attackers rather than compromised. At least 37% were registered in bulk, up from 27% the year before. Interisle counts a set as bulk when at least ten reported domains went through the same registrar less than ten minutes apart. Palo Alto Networks Unit 42 described clustering 842 domains registered within the same hour that all served a single gambling campaign. Infoblox reported detecting an average of 11,000 new registered-DGA domains per day in 2024.

Keyword search cannot keep up with this. It only finds domains whose names you guessed, on TLDs you remembered to check, and it misses random strings entirely.

The economics are what matter. A name costs an attacker almost nothing to change. Infrastructure does cost something. Configuring DNS for hundreds of domains is tedious, so attackers automate it and reuse it. That reuse leaves a trail defenders can follow.

The Nameserver as a Pivot

Each domain’s NS record, published in its TLD’s zone file, names the servers that answer DNS queries for it. Many domains can point to the same nameserver. Because the relationship is many-to-one, a nameserver can link domains whose names have nothing in common.

The method takes three steps:

1. Start with one confirmed malicious domain.
2. Look up its delegated nameservers.
3. Find every other domain delegated to those nameservers, across all TLDs, within a recent window.

Done early, this can surface sibling domains before a single phishing email goes out, while they are still parked or waiting for content. Delegation is also stable early in a domain’s life. The DarkDNS study (Sommese et al., ACM IMC 2024) found that 97.5% of newly registered domains kept their initial nameservers for their first 24 hours.

Domain search finds what an attacker named. Nameserver search finds what an attacker built.

Rarity Decides the Signal

How much a nameserver tells you depends on how many unrelated domains share it.

A private or rare nameserver, such as ns1.attacker-dns.example, is close to a campaign fingerprint. Almost nothing legitimate shares it, so a search on the nameserver alone can expose most of the operation.

A large shared provider, such as Cloudflare, Route 53, or a major registrar’s default DNS, serves millions of unrelated customers. On its own, that nameserver tells you almost nothing. The DarkDNS authors found that about half of the short-lived domains they confirmed used Cloudflare’s nameservers.

The usual fix for shared providers is to combine filters. Pair the nameserver with a brand wildcard (brand*) and a narrow time window, since bulk registrations cluster in time. Shared providers also leak a finer signal of their own.

What This Looks Like on a Shared Provider

To test this, we used ZoneFeeds to pull domains newly observed on Cloudflare nameservers across more than 1,000 gTLDs over eight days, October 17–25, 2026. On its own, the query is useless as a lead list. The results ran to three pages of 1,000 records each, and a single day’s snapshot filled the first page before reaching the end of one TLD.

The provider is too broad, but the nameserver pair is not. Cloudflare’s default is to use standard nameservers and to favor consistent nameserver names across all zones within an account. In practice, the specific pair of names behaves more like an account than a provider.

Grouping one day’s page of results by nameserver pair, about 125 domains fell into nine pairs. Each pair held a batch of machine-generated names of identical length. One pair alone carried 22 fifteen-letter random strings such as kcfkapcrodzgajo.shop. Four more pairs held similar fifteen-letter batches, and three held twelve-letter ones. None contained a brand term, so no keyword search would have found them. Every one had already dropped out of its zone when we looked, the short-lived pattern DarkDNS describes. Other pairs held readable series instead, such as nine near-identical kayservit-prefixed .shop names on a single pair.

The same view works in reverse. A keyword search for a generic term over the same window returned mostly domains on parking and aftermarket nameservers. Sixteen of them were a single portfolio sharing one aftermarket nameserver set. The nameserver column separated investor inventory from live infrastructure without opening a single site.

Not every result is a new registration. When we spot-checked results through RDAP, one domain in the Cloudflare set had been registered a year earlier and had simply moved nameservers. Two others had been registered on October 17, the first day of the window. Zone data records when a delegation was observed, not when the domain was registered.

Who Uses This

SOC analysts can go from one reported phishing domain to its unreported siblings and block them before they are used. Threat hunters can track nameservers that keep appearing in abuse reports. Brand protection teams can find lookalikes concentrated on a given provider and prioritise takedowns. Legal and takedown teams can show registrars that dozens of domains belong to one coordinated set, not isolated incidents.

The same search works defensively in-house. Enterprise IT can check that no unapproved domains point at company nameservers. It can also catch stale or lame delegations of the kind exploited in “Sitting Ducks” hijacking attacks. Infoblox and Eclypsium documented these in 2024, estimating that over a million domains were exploitable on any given day and that more than 35,000 had been hijacked since 2018. Portfolio managers can confirm that a DNS migration reached every domain. Researchers can measure DNS provider market share over time.

The Real Gap Is Freshness

Several commercial platforms already offer reverse nameserver search. The weak points are usually how current the data is and how much of the namespace it covers.

Zone files are snapshots. ICANN requires gTLD registries to provide zone file access at least daily, and users of its Centralized Zone Data Service (CZDS) can download each zone once per 24 hours. Registries update far more often. The DarkDNS authors observed .com and .net changing on average every 60 seconds and other gTLDs every 15–30 minutes. They found that daily snapshots miss at least 1% of newly registered, short-lived domains.

Coverage is uneven. CZDS covers gTLDs only. The zone file access obligation does not apply to ccTLDs, and most do not participate, though a few, such as .se, .nu, .ch and .li, publish their zones voluntarily.

New-domain feeds are often daily batches. Lower-latency streams exist, but they are typically separate paid products.

Passive DNS and certificate transparency see domains late, or not at all. Passive DNS needs someone to query the domain. CT needs a certificate to be issued. The DarkDNS team identified 42% of newly registered domains through CT logs before they appeared in daily CZDS snapshots; the rest had no certificate issued quickly enough to be seen that way.

Latency matters because abuse moves quickly. Interisle’s Phishing Landscape 2021 found that 57% of domains reported for phishing were used within 14 days of registration, and more than half of those within 48 hours. A batch that arrives the morning after registration may already be too late.

What to Look for in a Data Source

Whatever tooling you use, a few properties determine how well nameserver pivoting will work:

• Refresh frequency. This matters most, since daily snapshots, daily deltas and near-real-time streams catch very different populations of short-lived domains.
• TLD coverage. Check whether any ccTLDs are included, because CZDS alone will not provide them.
• Nameserver history. A domain that has since moved providers will not show up in a search of current delegations.
• Domains deleted between snapshots. Ask how the source handles them, because they are disproportionately the ones removed for abuse.

Options range from raw CZDS downloads and the handful of open ccTLD zones, through public research feeds such as the CT-based stream the DarkDNS authors released via OpenINTEL, to commercial reverse-NS, passive DNS and newly-observed-domain services. ZoneFeeds, from EUNOMATIX, which we used for the testing above, offers combined domain and nameserver search over daily gTLD zone data. Like any daily-snapshot source, it shares the freshness limits described above. In practice, combining sources narrows the gap more than any single one.

Caveats

Nameserver pivoting produces leads, not verdicts. Zone data shows delegation, not full DNS records, and it records when a delegation was seen, not when the domain was registered. Domains change nameservers, and capable attackers rotate providers. A shared nameserver, or even a shared pair, does not prove shared ownership. Cloudflare notes that conflicts can produce different nameserver names even within one account, and the same pair can serve unrelated accounts. Before acting, corroborate with registration date, registrar, RDAP data, hosting, and certificate transparency.

The Takeaway

Attackers will keep renaming things, because renaming is free. Rebuilding infrastructure is not. So search where attackers are least willing to change.