Domain Hijacking Monitor — Nameserver Change Alerts
Whoever controls the nameservers controls the mail.
An unexpected delegation change is the classic sign of a domain hijack: whoever controls the nameservers controls the mail, the website and the certificates. It is also the signal most monitoring tools cannot see, because it lives in the registry's zone file rather than in anything queryable from outside — and an empty result here is the good news.
oswaldocarabano/delegation-change-monitor
{
"domains": [
"alabamapayroll.com",
"ecopayroll.com",
"agileinvoice.com"
],
"days": 30,
"maxResults": 100
}- Version
- v0.1.8
- Memory
- 4096 MB
- Browser
- none
- Proxy
- None — the zone data is held, not fetched
Short answer
The Domain Hijacking Monitor Actor watches a list of up to 5,000 domains and reports when their nameservers change in the registry zone, across 1,075 gTLDs. An unexpected delegation change is the classic sign of a domain hijack, because whoever controls the nameservers controls the mail, the website and the certificates. Each row carries both the previous and the current delegation plus a `change_type`: `nameserver_change` inside the same provider is usually routine maintenance, while `provider_change` on a domain nobody migrated is the one worth waking somebody up for. The delegation fact is 100% reliable — these nameservers were in yesterday's snapshot and different ones are in today's — but it is one snapshot a day, so a hijack at 09:00 shows up in tomorrow's run.
Key points
- Whoever controls a domain's nameservers controls its mail, its website and its certificates, which is why an unexpected delegation change is the classic first sign of a hijack.
- Delegation lives in the registry's zone file rather than in anything queryable from outside, which is why most domain monitoring services cannot see this signal at all.
- The `change_type` field separates the two cases that matter: `nameserver_change` inside one provider is usually routine maintenance, while `provider_change` on a domain nobody migrated is an incident.
- The delegation fact is 100% reliable: these nameservers were in yesterday's snapshot and different ones are in today's, which is the registry's own record rather than an inference.
- One snapshot a day means a hijack at 09:00 appears in tomorrow's run — far earlier than most organisations notice, and not real-time.
- An empty result is the good news and costs only the $0.00001 start fee, because nothing changed hands on any domain being watched.
- A delegation that moves onto a parking or domain-sale service usually means the owner is selling rather than that anything was hijacked, which `parked_for_sale` makes visible on the new nameservers.
What it does
An unexpected delegation change is the classic sign of a domain hijack: whoever controls the nameservers controls the mail, the website and the certificates. It is also the signal most monitoring tools cannot see, because it lives in the registry's zone file rather than in anything queryable from outside — and an empty result here is the good news.
{
"domain": "agileinvoice.com",
"tld": "com",
"observed_on": "2026-09-16",
"previous_nameservers": ["ns1.digitalocean.com", "ns2.digitalocean.com"],
"nameservers": ["dns1.registrar-servers.com", "dns2.registrar-servers.com"],
"change_type": "provider_change",
"dns_provider": "Namecheap",
"parked_for_sale": false
}Why this one
A signal that is not visible from outside
Uptime monitors watch whether a site answers; certificate monitors watch what is issued; DNS monitors query the domain's own records. None of those see the delegation itself change in the registry's zone, which is the layer above all of them and the one an attacker who took the registrar account moves first.
Two kinds of change, told apart
A monitoring tool that alerts on every nameserver change trains its owner to ignore it, because routine maintenance inside one provider fires constantly. `change_type` splits `nameserver_change` from `provider_change`, so the alert that means a different organisation now runs the DNS is separable from the one that means a provider renumbered its servers.
Both sides of the change in the row
`previous_nameservers` and `nameservers` are both returned, so the first question an incident responder asks — where did it go, and where was it before — is answered by the row rather than by a second lookup. The fact is a comparison between two registry snapshots, and the output shows both halves of it.
Latency stated rather than implied
One snapshot a day, and a hijack at 09:00 shows up tomorrow. That is still far earlier than most organisations notice a delegation change, and it is not real-time. Saying which of the two it is, in the README, is what lets somebody decide whether this belongs in their incident process or beside it.
Use cases
- Monitor a company's own domain portfolio daily for unexpected delegation changes.
- Watch a client portfolio as an agency, and treat an empty result as a clean day.
- Detect that a domain has moved onto a parking service, which usually means a sale rather than an incident.
- Track delegation changes involving a specific DNS provider during a migration.
- Add a registry-level check to an incident process that already watches uptime and certificates.
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 |
|---|---|---|
domainsstring[] | [] | Domains to watchThe domains to monitor, one per line, up to 5,000. This is the normal way to use the Actor: an own portfolio, or a client's. |
providerstring[] | [] | DNS provider filterOptional. Instead of a domain list, report changes involving this DNS provider, matched on the nameserver hostname. Always bounded by the look-back window. |
daysinteger | 7 | Days to look backpersonal dataHow many daily snapshots to search. Required and capped at 90 — there is no 'since forever', by design. |
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% | The domain whose delegation changed in the window searched. |
tldstring | 100% | The top-level domain, one of the 1,075 covered gTLDs. |
observed_onstring | 100% | The date of the snapshot where the change appeared, which is the certain part of the row. |
nameserversstring[] | 100% | Where the domain delegates now, as recorded in the newer snapshot. |
previous_nameserversstring[] | 100% | Where it delegated before, so the incident question 'where was it' is answered by the row rather than a second lookup. |
change_typestring | 100% | `provider_change` when the DNS operator changed, `nameserver_change` when the same operator moved servers. The field that separates an incident from maintenance. |
dns_providerstring | 69.1% | Who runs the DNS now, inferred from the new nameservers. |
parked_for_saleboolean | 100% | True when the new nameservers belong to a parking or domain-sale service, which usually means the owner is selling rather than that anything was hijacked. |
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 delegation change, carrying both the previous and the current nameservers.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 on a watched portfolio that is the outcome you want every day. |
delegation-changeDelegation change | $0.004 | One domain whose nameservers changed in the registry zone, with both the old and the new delegation. An unexpected change is the classic sign of a domain hijack. |
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.
Delegation fact reliability
100%
These nameservers were in one daily snapshot and different ones are in the next. The comparison is the registry's own record and carries no inference.
Detection latency
one snapshot a day
The registries publish zone files once a day, so a change at 09:00 appears in the following day's run. Earlier than most organisations notice, and not real-time.
`dns_provider` fill rate
69.1%
Measured across every domain in the zone. A change involving an unrecognised nameserver still reports the hostnames, without an operator name.
Watch list size
up to 5,000 domains per run
The input cap. Combined with the 90-day window and the row cap, it is what keeps the Actor bounded to portfolios rather than to the namespace.
What it will not do
Stated plainly so you can judge fit before spending anything.
- One snapshot a day: a hijack at 09:00 appears in tomorrow's run, so this is early warning rather than real-time detection.
- A change you made yourself is still a change, and the Actor cannot tell an authorised migration from an unauthorised one.
- Country-code TLDs are not covered, so a `.io` or `.co` domain in a portfolio cannot be watched here.
- A zone file contains no registrant, no email and no registrar, so a change cannot be attributed to whoever made it.
- Up to 5,000 domains per run, and the service never returns more than 50,000 rows in one run.
- The optional provider filter is always bounded by the look-back window, which is capped at 90 days.
- `dns_provider` is filled on 69.1% of rows, so a change involving an unrecognised nameserver arrives without an operator name.
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.
- The Actor is built for monitoring what the operator is responsible for: their own portfolio, their clients', or infrastructure they are investigating.
- Every run is bounded by a 90-day window and a hard row cap, and no input can return a substantial portion of a zone.
- Removal requests: privacy@actorstack.dev
See also the data removal process.