Monitor the Registration, Not the Website
The most common monitoring mistake is watching the wrong object. Uptime checks, page-content diffs and certificate expiry alerts all watch the service. The theft happens to the registration, and by the time the service is visibly affected, the transfer has usually completed.
The value of monitoring is one number: the time between an unauthorized change and someone noticing. In the publicly reported e-hawk.net theft, the domain was moved out on 23 December 2019 and moved again three days later; the owners discovered it on 13 January 2020, when DNS was finally changed. Three weeks passed in which the registration record said, in public, that the domain had changed hands.
The second is treating the registrar's dashboard as the monitor. If the scenario you are guarding against is a compromised registrar account, the attacker sees that dashboard too, can silence its notifications and can change where they are sent. Monitoring has to be independent of the system being monitored, which means polling registration data from outside.
The Five Signals Worth Alerting On
Almost everything that matters is visible in registration data and DNS, and it reduces to five signals. I would page a human for any.
- Nameserver change. The delegation is the asset in practical terms. An attacker who repoints nameservers controls the website, the mail, and through it the ability to obtain certificates, without ever moving the registration. A nameserver change you did not schedule is the highest-urgency DNS-layer signal there is.
- Registrar of record change. The theft completing. Earlier and better:
pendingTransfer, which ICANN documents as a transfer request received and being processed, with guidance to act if you did not initiate it. It is the highest-value alert in the discipline because it fires while the transfer is still contestable. - Status code change. Any delta in the EPP status codes, either direction. A lock appearing that you did not request matters; a lock disappearing matters more, for reasons covered next.
- Registration data change. Registrant, administrative or technical contact edits — particularly the contact email, where every confirmation and recovery message goes. Changing it is frequently an attacker's first move, because it redirects the alarms before the theft.
- Expiry approaching. Unglamorous, and the most common way domains are actually lost. Fully preventable, and it deserves first-class treatment rather than a calendar reminder.
Note what these share: each is a state change in a record you do not control, published by a party other than your registrar, observable without privileged access.
Lock Removal Is the Precursor, Not the Event
If you take one operational detail from this page, take this. Monitoring for pendingTransfer tells you a transfer is in flight. Monitoring for a clientTransferProhibited or clientUpdateProhibited code disappearing tells you something earlier and more useful: someone with registrar-level authority just cleared the obstacle to a transfer.
The sequence in a typical account-compromise theft runs: credentials obtained, contact email changed, lock removed, authorization code retrieved, transfer initiated, transfer completes. Most monitoring fires at step five. The lock disappearing is step three, and on that timeline you still have a registrar to call rather than a registrar-to-registrar dispute to open.
So alert on deltas in the status list, not on known-bad values. A monitor configured to alarm when pendingTransfer appears is a monitor that stays silent through the entire preparation phase of the attack it exists to catch.
The same logic applies at the registry layer. If a domain is registry locked, the presence of all three server-prefixed prohibitions is itself a monitorable fact, and any one going missing is worth a phone call the same day.
Vanity Alerts, and Why They Cost More Than Nothing
Monitoring products compete on signal count, which produces alerting that looks like security and functions as noise. My view, stated plainly because someone should:
- Website uptime as domain monitoring. Worth having, but it is not this. It detects the last step of a hijack, long after the recoverable window narrowed.
- Typosquat and lookalike registration feeds, absent an enforcement plan. Brand watching is a legitimate and separate discipline: it feeds trademark enforcement, not incident response. Subscribed to with nobody budgeted to act on the results, it produces a weekly list nobody reads and trains the team to ignore the console that also carries the real alerts.
- Undifferentiated “WHOIS changed” alerts. Registration data changes for dull reasons constantly; a monitor that treats a registrar's bulk update of its own abuse contact the same as a registrant email change teaches people to dismiss the category.
- Social and brand mention monitoring filed under domain security. Useful to marketing. Unrelated to whether you still control the name.
- Daily digests for signals needing an hour's response. A nameserver change reported in tomorrow's summary is a report, not an alert.
The cost is not the subscription. It is attention: a channel that mostly carries things nobody must act on gets muted, and it gets muted before the one message that mattered arrives. Route the five signals above to a channel carrying only those five. Everything else belongs in a report.
Where the Data Comes From
Query RDAP, the structured JSON successor to WHOIS. Since 28 January 2025, ICANN states that RDAP is “the definitive source for delivering generic top-level domain name (gTLD) registration information in place of sunsetted WHOIS services,” and that all gTLD registries and registrars must provide RDAP using the gTLD RDAP Profile while no longer being required to provide WHOIS, except for .com, .name and .post.
For monitoring this is an improvement rather than an administrative detail. RDAP returns structured JSON, so status codes, dates, nameservers and registrar of record can be diffed reliably instead of regex-scraped out of free-form text every registry formats differently. Tooling built on port-43 WHOIS parsing should be migrated — and .com and .net expose the gap neatly, since .com retains a WHOIS obligation and .net does not.
Redaction limits what you can see but not what matters. Contact fields are largely empty under ICANN's Registration Data Policy, while the fields worth diffing — domain status, nameservers, registrar and IANA ID, creation date, registry expiry date — all remain published. You lose the ability to see who the new registrant is. You keep the ability to see that something changed, which is what an alert is for.
Poll on a schedule matching the urgency you claim. Daily polling means an attacker holds a domain for up to a day before you know, usually acceptable; weekly polling is not monitoring in any meaningful sense.
The Layers Registration Data Cannot See
Registration data tells you about the registration. Two important attack paths do not appear in it at all.
Zone contents. The parent's nameserver delegation is visible in registration data; the records those nameservers serve are not. A hijack that changes MX records to intercept mail leaves the registration looking pristine, is quieter than a website redirect, and is found much later. Monitor A, AAAA, MX and TXT records from outside, plus the presence of the DS record if the zone is signed.
Certificate issuance. Certificate Transparency logs publicly record certificates as they are issued. Monitoring them catches an attacker who obtained a certificate for your name — including issuance a CAA record did not block, and issuance predating your CAA record. CAA constrains future issuance by compliant authorities, raises no alert of its own unless an iodef reporting address is set, and says nothing about certificates that already exist.
CISA's Emergency Directive 19-01, issued 22 January 2019, validates this model from the attacker's side: compromise credentials for an account that can change DNS records, alter those records to redirect traffic, then obtain valid encryption certificates for the organization's domain names. Its required actions map onto the same three layers — audit DNS records, secure the accounts that can change them, monitor Certificate Transparency logs.
Expiry Is a Monitoring Problem, Not a Calendar Entry
More domains are lost to expiry than to theft, and the alerting is already built in — routed, unhelpfully, through the same email address an attacker would change.
ICANN's Expired Registration Recovery Policy, effective 31 August 2013, requires registrars to send a renewal reminder roughly one month before expiration and another roughly one week before, plus a notice within five days after expiration if the name has not been renewed or deleted. It also requires the registrar to interrupt the existing DNS resolution path after expiration, for at least eight consecutive days while the name is still renewable.
Treat those notices as scheduled checkpoints and the expiry date as an independently monitored field, because the built-in reminders share the failure mode of every other registrar notification: they go to one address, and that address is the first thing an attacker changes and the first to go stale when someone leaves.
After expiry the clock does not stop. A deleted domain enters the redemption period, which ICANN describes as holding it for 30 days before deletion, and restoring it from there carries a registry fee well above a normal renewal. All of it is avoidable at the cost of one monitored date field.
The Alerting Channel Is Part of the Control
A monitoring program is only as good as the path its alerts travel, and this is where competent setups fail.
- Do not send alerts to a mailbox on the domain being monitored. An attacker who repoints your MX records captures the alarm with the asset. SAC044 made this point in 2010 and it remains the most-ignored recommendation in the field.
- Do not send them to a personal address. People leave, change roles and take vacations. Use a role-based mailbox more than one person reads.
- Do not send them only inside the registrar account. The account is the thing under attack.
- Confirm anonymized forwarders actually deliver. Under privacy services the published contact is a forwarder; if nobody reads what it forwards to, expiry notices, transfer confirmations and dispute notices are missed silently.
- Test the path on a schedule. An alerting channel that has never fired is an assumption, not a control.
One more thing belongs in a monitoring program even though it is not an alert: a current, offline evidence pack — registrar account records, renewal invoices, dated registration-data snapshots, DNS zone exports. Detection buys time; evidence is what you spend it on. Assembling that material after a theft, under redaction, against a clock is far harder than keeping it current — and where a name has already moved, the matter needs counsel experienced in domain disputes rather than a better dashboard.