A delegation change is the first visible sign of a domain hijack
Whoever controls the nameservers controls the mail, the site and the certificates. That change happens in the registry zone, which is the one layer most monitoring never looks at.
An attacker who takes over a registrar account moves the delegation first, because whoever controls a domain's nameservers controls its mail, its website and the certificates that can be issued for it. That change is recorded in the registry's zone file, which is the layer above everything ordinary monitoring watches: an uptime monitor sees a site that still answers, a certificate monitor sees a certificate that was validly issued to whoever now controls DNS, and a DNS monitor queries the nameservers the attacker chose. Comparing two daily zone snapshots makes the change visible, with `change_type` separating a provider change from routine renumbering inside one operator.
Key points
An attacker with a registrar account moves the delegation first, because control of the nameservers carries mail, web traffic and certificate issuance with it.
Delegation changes are recorded in the registry zone file rather than anywhere queryable from the domain itself, which is why most monitoring cannot see them.
An uptime monitor sees a site that still answers and a certificate monitor sees a certificate that was validly issued, so neither raises an alarm on a hijack.
`change_type` separates `provider_change`, where a different operator now runs the DNS, from `nameserver_change` inside one provider, which is usually maintenance.
Each row returns the previous and the current delegation together, so the first incident question is answered by the row rather than by a second lookup.
Detection is one snapshot a day, which is far earlier than most organisations notice a delegation change and is not real time.
A domain hijack does not start with a defaced homepage. It starts one level above everything you are watching.
Why an attacker moves the delegation first
Whoever controls a domain's nameservers controls where its mail goes, where its web traffic lands, and what certificates can be validly issued for it. An attacker who has taken a registrar account changes the delegation because that single change carries all three with it. Everything else follows.
The layer most monitoring never looks at
Monitor
What it sees after a hijack
MonitorUptime
What it seesA site that answers normally
MonitorCertificate transparency
What it seesA certificate validly issued to whoever now controls DNS
MonitorDNS record checks
What it seesRecords served by the attacker's nameservers
MonitorRegistry zone comparison
What it seesThe delegation itself changed
The first three query the domain and get an answer from infrastructure the attacker now chooses. The fourth reads the registry's own record, which the attacker changed but cannot disguise.
Telling an incident from maintenance
Alert on every nameserver change and you will be ignored within a month, because providers renumber their servers routinely. change_type splits the two: nameserver_change is movement inside one operator, and provider_change means a different organisation now runs the DNS. On a domain nobody migrated, the second is the one worth waking somebody up for.
Where it went and where it was, in the row. If parked_for_sale had fired on the new delegation, the likely story would be a sale rather than a theft — which is a different phone call.
One snapshot a day, and what that means
A hijack at 09:00 appears in tomorrow's run, because the registries publish once a day. That is considerably earlier than most organisations notice a delegation change and it is not real time, and pretending otherwise would put it in the wrong place in an incident process.
Fitting it into an incident process
As a daily control alongside real-time ones, over the domains you are responsible for. An empty result is the good news and costs only the start fee — and the nameservers a change points at can be pivoted on when a result is not empty.
Frequently asked questions
▸How would I know my domain was hijacked?
The earliest visible sign is usually the delegation itself changing in the registry zone, because that is the step an attacker takes first. Comparing daily zone snapshots for the domains you are responsible for surfaces it without depending on anyone noticing a symptom.
▸Why doesn't my uptime monitoring catch this?
Because the site still answers. After a delegation change the attacker's nameservers serve records that point wherever they like, so an uptime check, a certificate check and a DNS query against the current nameservers all look healthy.
▸How do I avoid alerts on routine maintenance?
Read `change_type` before anything else. A `nameserver_change` inside the same provider is usually that provider renumbering its servers, while `provider_change` means a different organisation now runs the DNS — which on a domain nobody migrated is the one to act on.
▸Is this real-time detection?
No, it is one snapshot a day, so a change at 09:00 appears in the following day's run. That is still considerably earlier than most organisations notice a delegation change, and it should sit alongside real-time controls rather than replace them.
Sources
Every URL below was requested and returned a page on the date shown.
How to run a brand sweep across 1,075 gTLDs, how to read `exact`, `typo` and `contains` differently, and why an empty result is the outcome worth paying for.
Zone entry is the earliest public signal that a domain went live, and roughly 20–30% of those events are re-appearances rather than new registrations. The number is an outside estimate and is labelled as one.
Screening a naming shortlist against zone files instead of querying WHOIS per name: what it costs, what the verdicts mean, and where the method stops being enough.
