Detecting domain registration changes before they cause damage

An attacker gains access to a registrar account through a compromised email address. They change the nameservers. Traffic that should reach your servers gets redirected to theirs. The legitimate domain owner notices 48 hours later because "something seems off" with the site. If a domain change detection system had been in place, the nameserver change would have triggered an alert within hours of it happening, the difference between two days of damage and two hours.

This article covers what can change in domain registration data, what each type of change means, and how to configure automatic detection.

What can change in a domain's registration data

Not all changes carry the same risk. It helps to categorize them.

Operational fields, immediate impact possible:

• Nameservers: determines where DNS queries are resolved. An unauthorized nameserver change redirects all traffic, your website, your email, any service using that domain. This is the clearest indicator of active domain hijacking.
• EPP statuses: the removal of clientTransferProhibited is often the first step in initiating a transfer. The appearance of clientHold means DNS resolution has already stopped.
• Registrar: a registrar change outside of a transfer you authorized is a strong indicator of hijacking. This is relatively rare but serious when it happens.

Informational fields, strategic or administrative signals:

• Registrant name or organization: a change in ownership.
• Registrant email: contact change. If unauthorized, this is often a precursor to account takeover.
• Expiration date: advancing or pushing back the expiration date.

Transitional fields, normal, indicate an operation in progress:

• pendingTransfer: a transfer has been initiated.
• pendingUpdate: a data modification is being processed.

The anatomy of a domain hijack in RDAP data

Here's how a typical hijack unfolds, mapped to what RDAP would show at each step:

1. The attacker compromises the email account associated with the registrar account. Nothing appears in RDAP yet, this step is invisible at the domain level.
2. The attacker changes the registrar account email. If the registrar updates WHOIS with the new registrant email, this appears in RDAP as a registrant contact change.
3. The attacker removes clientTransferProhibited and initiates a transfer to another registrar, or changes the nameservers directly. RDAP now shows: status change, new nameservers, potentially pendingTransfer.
4. DNS propagates to the new nameservers. Depending on TTL values, this can take minutes to hours.

Steps 3 and 4 are detectable via RDAP diff. Steps 1 and 2 may not appear immediately, but by the time the attacker moves to step 3, there's a detectable signal.

Account hijack vs. domain hijack: the difference

A registrar account compromise doesn't immediately appear in RDAP. The account could be breached without any domain-level changes being visible. Domain change detection catches the consequences of an account breach (when nameservers or statuses are modified) not the breach itself. It's a complementary layer of defense, not a replacement for account security (strong passwords, 2FA on your registrar account).

Legitimate reasons RDAP data changes

Before treating every change as suspicious, it's worth knowing the expected change patterns. False positives waste time and erode trust in the alerting system.

Common legitimate changes:

• Annual renewal updates the expiration date.
• Planned hosting migration changes nameservers.
• Authorized inter-registrar transfer.
• Updating registrant contact information (new address, merged company).
• Enabling or disabling WHOIS privacy protection (may change registrant data visibility).

The practical advice: keep a log of planned domain operations. When an alert fires, check the log first. If the change matches a planned operation, acknowledge it. If it doesn't, investigate immediately.

How Domain Sentinel detects data changes

At each verification cycle, Domain Sentinel queries RDAP for every domain in your watchlist and stores the result. On the next cycle, it compares the new response against the stored snapshot field by field. Any field that differs from the previous value generates a change event.

The alert contains the specific field that changed, the previous value, and the new value. That's enough to assess immediately whether the change was expected.

What Domain Sentinel compares (and what it ignores)

Not every field difference is meaningful. Registries sometimes update internal timestamps or formatting without any meaningful change to the domain's actual state. The comparison focuses on operationally significant fields: nameservers, EPP statuses, registrar, expiration date, and registrant contact data. Routine timestamp updates that registries append to records aren't treated as alert-triggering changes.

How to respond to a suspicious change

When an alert fires and you don't recognize the change, time is the critical variable. The faster you act, the less damage gets done.

1. Nameservers changed unexpectedly: check whether your DNS resolver still returns the old nameserver responses, this tells you if the change has propagated. Log the new nameserver values. If you didn't authorize the change, contact your registrar's abuse/security team immediately.
2. clientTransferProhibited removed: contact your registrar right now and request that the transfer lock be reinstated. If a transfer is already in progress, you have a window to reject it (typically 5 days for .com).
3. Registrar changed without an authorized transfer: contact the ICANN Registrar Ombudsman and your original registrar with proof of ownership. This is the most serious scenario and may require formal escalation.
4. Registrant email changed: this is often a sign of an account takeover in progress. Initiate emergency account recovery through your registrar's support channel, not through the email address on the compromised account.

Domain change detection functions like a security camera on your domains. It doesn't prevent attacks, but it collapses the detection window from days to hours. For domain hijacking, that difference is often the difference between a recoverable incident and a permanent loss.