Reverse Nameserver Lookup — Find Domains on a DNS Host
The registry's view of delegation, not a sample of it.
Reverse nameserver lookup is the query that is genuinely hard to answer any other way: passive DNS providers approximate it from observed traffic, which means what they return depends on what they happened to see. Reading the zone files answers it from the registry's own record of delegation instead — and the honest caveat, stated in the README, is that the answer is only meaningful on a nameserver that belongs to one organisation.
oswaldocarabano/reverse-nameserver-lookup
{
"nameserver": ["ns1.digitalocean.com", "ns2.digitalocean.com"],
"maxResults": 500
}- Version
- v0.1.10
- Memory
- 4096 MB
- Browser
- none
- Proxy
- None — the zone data is held, not fetched
Short answer
The Reverse Nameserver Lookup Actor returns the domains delegated to a given nameserver across 1,075 gTLDs, read from the registries' own zone files rather than approximated from observed DNS traffic the way passive DNS providers do. Each row carries the domain, every nameserver it delegates to, whether it publishes DNSSEC, the inferred DNS provider and whether it sits on a parking service. Pivoting is only meaningful on a custom nameserver that belongs to one organisation: looking up `ns1.cloudflare.com` honestly returns tens of millions of unrelated domains, because Cloudflare alone is 20.9% of the namespace. Pricing is $0.003 per domain found, and an empty result — meaning that nameserver hosts nothing else in the covered zones — costs only the $0.00001 start fee.
Key points
- Passive DNS providers approximate reverse nameserver lookup from observed traffic, so their answer depends on what they happened to see; a zone file is the registry's own record of delegation.
- Pivoting is only meaningful on a custom nameserver belonging to one organisation, because Cloudflare alone accounts for 20.9% of the namespace and a lookup there returns tens of millions of unrelated domains.
- Two domains sharing a big provider's nameservers have nothing to do with each other, while two domains on the same obscure self-run nameserver very often do — which is why `dns_provider` has to be read before any conclusion is drawn.
- DNSSEC adoption sits at 5.0% of domains globally but ranges from 0% to 100% by registry — 14.1% in `.dev`, 5.5% in `.net` and 0.9% in `.bond` — so a low rate is a fact about the TLD rather than a finding about the domain.
- An empty result is a real answer rather than a failure: that nameserver currently hosts nothing else in the covered zones, and it costs only the $0.00001 start fee.
- Country-code TLDs are not covered at all, so a lookup returns the gTLD portion of a nameserver's footprint and never the whole of it.
What it does
Reverse nameserver lookup is the query that is genuinely hard to answer any other way: passive DNS providers approximate it from observed traffic, which means what they return depends on what they happened to see. Reading the zone files answers it from the registry's own record of delegation instead — and the honest caveat, stated in the README, is that the answer is only meaningful on a nameserver that belongs to one organisation.
{
"domain": "example-client.dev",
"tld": "dev",
"nameserver": "ns1.digitalocean.com",
"all_nameservers": [
"ns1.digitalocean.com",
"ns2.digitalocean.com",
"ns3.digitalocean.com"
],
"dnssec": true,
"dns_provider": "DigitalOcean",
"parked_for_sale": false
}Why this one
A record rather than a sample
Passive DNS builds its picture from queries it observed, so a domain nobody looked up is a domain it does not know about, and coverage is a property of the sensor network rather than of the namespace. Zone files are what the registry publishes about delegation. The two answer differently-shaped questions, and this one says which it is answering.
The caveat that limits its own usefulness, in the README
Looking up `ns1.cloudflare.com` returns tens of millions of unrelated domains and the row cap stops the run long before the result is useful. Rather than let that be discovered on a paid run, the README states where the Actor earns its keep: a company's own `ns1.company.com`, a small hosting provider, a specific infrastructure under investigation.
Shared hosting is not a relationship
The mistake this output is shaped to prevent is treating co-location on a nameserver as evidence of a link. Two domains on a big provider's nameservers share a vendor and nothing else. `dns_provider` is on every row precisely so the two cases can be told apart before somebody writes a report asserting a connection that does not exist.
DNSSEC with its own denominator
`dnssec` is returned per domain, and the README publishes the rates that make it readable: 5.0% globally, 14.1% in `.dev`, 5.5% in `.net`, 0.9% in `.bond`. Without those, a security report reads 5% adoption as a weakness of the domains rather than as the current state of the registry they sit in.
Use cases
- Inventory every domain delegated to an organisation's own nameservers, across TLDs nobody remembers registering.
- Map the infrastructure behind a specific self-run nameserver during a security investigation.
- Find the other domains on a nameserver that hosts suspended or seized domains.
- Audit which domains still delegate to a DNS provider being migrated away from.
- Check the gTLD footprint of a small hosting provider without querying anybody's registry.
Input
Every field has a default, and the defaults are deliberately small so a first run is cheap enough to inspect before you commit to a sweep. This table mirrors the Actor's own input schema field for field.
| Field | Default | What it does |
|---|---|---|
nameserverstring[] | [] | Nameserverpersonal dataThe nameserver hostnames to look up, for example `ns1.example-dns.com`. Pivoting is only meaningful on custom nameservers that belong to one organisation. |
maxResultsinteger | 100 | Max resultspersonal dataHard cap on rows returned, kept low on purpose so a first run cannot burn a free credit. The service never returns more than 50,000 rows in one run. |
Output and fill rates
A field being in the schema is not the same as it having a value. The percentages below were counted on real runs; the sample sizes are in Measurements. Anything not listed here is not promised.
| Field | Filled | Meaning |
|---|---|---|
domainstring | 100% | A domain delegated to the nameserver asked about, as recorded in the registry zone. |
tldstring | 100% | The top-level domain, one of the 1,075 covered gTLDs. |
nameserverstring | 100% | The nameserver that matched, which matters when several were supplied in one run. |
all_nameserversstring[] | 100% | Every nameserver this domain delegates to, so a partial migration is visible rather than hidden behind the one that matched. |
dnssecboolean | 100% | Whether the domain publishes a DS record. 5.0% of domains do, ranging from 0% to 100% depending on the registry. |
dns_providerstring | 69.1% | Who runs the DNS, inferred from the nameserver. A hosting fact rather than a technology one. |
parked_for_saleboolean | 100% | True when the nameserver belongs to a parking or domain-sale service. Fires on 2.0% of domains and is exact when it does. |
Every key is always present. A field that exists but is empty comes back as explicit null, so a parser never has to guess.
Datasets
Different record types go to different datasets, so the main table never carries columns that are blank on most rows.
defaultOne row per domain delegated to the nameserver, with its full delegation and DNSSEC state.billed
Pricing
Pay per delivered result. Charges are applied as each row is produced rather than in a lump at the end, so an aborted run bills only for what it actually gave you.
| Event | Price | Notes |
|---|---|---|
actor-startActor start | $0.00001 | Effectively free. A run that finds nothing costs you nothing, and finding nothing is a real answer here. |
domain-foundDomain found | $0.003 | One domain delegated to the nameserver asked about, with every nameserver it uses and whether it publishes DNSSEC. Built from zone files, so it is the registry's own record of delegation rather than a passive DNS sample. |
Measurements
Each figure is shown with the method that produced it. A benchmark without a method is a marketing claim wearing a number's clothes.
Zone coverage
255,631,856 domains across 1,075 gTLDs
Counted from the zone files themselves rather than quoted from a registry summary, and refreshed daily.
Namespace concentration
Cloudflare is 20.9% of the namespace
Counted across every domain in the zone by matching nameservers to operators. It is the reason a lookup on a large provider's nameserver is not a useful pivot.
DNSSEC adoption
5.0% of domains, 0% to 100% by registry
Counted across the whole zone and per TLD: 14.1% in `.dev`, 5.5% in `.net`, 0.9% in `.bond`. Published so a low rate is read as a fact about the TLD.
`dns_provider` fill rate
69.1%
Measured across every domain in the zone. The remaining 30.9% delegate to nameservers that identify no known operator.
`parked_for_sale` rate
2.0% of domains
Measured across the whole zone by matching nameservers against known parking and domain-sale services. Exact when it fires.
What it will not do
Stated plainly so you can judge fit before spending anything.
- A lookup on a large provider's nameserver returns tens of millions of unrelated domains and the row cap will stop it long before the result is useful.
- Co-location on a nameserver is not a relationship between domains, and the output deliberately does not assert one.
- Country-code TLDs are not covered, so the result is the gTLD portion of a nameserver's footprint rather than all of it.
- A zone file contains no registrant, no email, no registrar and no registration or expiry date, so a lookup cannot attribute a nameserver to a person.
- `dns_provider` is filled on 69.1% of rows and names who runs the DNS, not what the site is built with.
- Zone data is refreshed once a day, so a delegation made this morning may not appear until tomorrow's snapshot.
- The service never returns more than 50,000 rows in one run.
Privacy
- Zone files contain delegation records, not people: there is no registrant, no email address and no registrar in the source.
- The data is obtained through ICANN's Centralized Zone Data Service under agreement with the Registry Operators, and ICANN does not endorse, sponsor or review this Actor.
- No WHOIS or RDAP query is made at any point, because querying registries at scale is prohibited by the agreement that provides this data.
- Every run is anchored on a nameserver the operator supplies, and no input can return a substantial portion of a zone.
- Removal requests: privacy@actorstack.dev
See also the data removal process.
Frequently asked questions
How is this different from a passive DNS reverse lookup?
Can I look up ns1.cloudflare.com?
Do two domains on the same nameserver belong to the same owner?
What does a 5% DNSSEC rate tell me about a domain?
Does an empty result mean the lookup failed?
Will it find domains in ccTLDs on that nameserver?
Guides for this Actor
- Reverse nameserver lookupPivoting from a nameserver to the domains delegated to it is useful on infrastructure that belongs to one organisation and useless on a large provider's. The difference is the whole technique.
- DNSSEC adoption by TLDMeasured across the whole zone, 5.0% of domains publish a DS record. Per registry the rate runs from 0% to 100%, which is what makes the global figure unusable on its own.