Skip to content

Part 4 of 7 · Domain renewal watcher series ~5 min read

How domain status codes are read

An expiry date is a scheduled event and everything else the registry tells you is news. A domain can be suspended, in a redemption period, or pending deletion with an expiry date that is still months away, and a watcher that only reads the date will report all of those as fine.

Key takeaways

  • Status codes carry situations the expiry date cannot express.
  • Three families: protective locks, registrar actions, and the deletion lifecycle.
  • Missing protective locks on an important domain is a finding in itself.
  • An unexpected nameserver change is the loudest signal the registry can give you.
  • Every change is reported; only some changes are alarming.

Three families of code

FamilyExamplesWhat it means
ProtectiveclientTransferProhibited, clientUpdateProhibitedThe domain is locked against transfer or change. You want these.
Registrar actionclientHold, serverHoldThe registrar or registry has stopped resolving it. Usually payment or abuse.
LifecycleredemptionPeriod, pendingDeleteIt has already expired and is on a clock. Days matter now, not months.

The lifecycle family is the one that catches people. A domain that expired last month is not gone — it goes through a redemption period during which it can usually be recovered for a fee, and then a pending-delete window after which it is released. A watcher that reports on expiry dates and stops reporting once a domain expires has gone quiet at precisely the point where a few days matter.

What each change triggers

How domain status code changes are triagedA vertical chain of five steps entered by a box labelled This week's status, from the registry. Step one asks whether it changed from last week; no exits to Nothing to say, the usual outcome. Step two asks whether a hold appeared, client or server; if so it exits to Alarm now, because the domain is not resolving. Step three asks whether a lifecycle code is present such as redemption period or pending delete; if so it exits to Alarm with the days left and the recovery cost. Step four asks whether a lock disappeared, such as a transfer prohibition; if so it exits to Ask why, since it is either a transfer or a mistake. Step five reports the change quietly in the digest. A note says a lock disappearing on a domain nobody is transferring is worth a phone call.AWS ACCOUNTThis week's statusfrom the registryChanged from last week?Nothing to saythe usual outcomenoA hold appeared?client or serverAlarm nowthe domain is not resolvingyesLifecycle code?redemption, pendingDeleteAlarm, with days leftand the recovery costyesA lock disappeared?transfer prohibition goneAsk whya transfer, or a mistakeyesReport the changequietly, in the digestA lock disappearing on a domain nobody is transferring is worth a phone call.
Fig 1. How a status change is handled. Three of the four branches alarm, which is unusual for this series and reflects that status codes only change when something has happened.
  • App integration
  • Machine learning
  • Networking
  • Management
  • Analytics

Missing locks

The protective codes are the ones you want present, and their absence on an important domain is a finding the register should raise once rather than an alarm it repeats. A domain without clientTransferProhibited can be transferred away with less friction than one that has it, and turning it on is a single setting in every registrar dashboard.

So the weekly check includes a one-off note: “example.com has no transfer lock. Most registrars offer this free.” Once acknowledged, it is not raised again unless the situation changes.

Nameservers

Not a status code, and the loudest thing on the whole record. Nameservers change when somebody moves hosting, and they change when somebody has taken control of a domain. Both are rare, and the second is the reason this is checked weekly rather than monthly.

How an unexpected nameserver change is escalatedA horizontal row of five boxes. NS changed: since last week. Expected: nobody said so. Alarm: immediately, to two people. Both old and new: included in the message. Usually: a migration nobody mentioned. A note says nine times in ten it is a migration, and the tenth is why it goes to two people.AN UNEXPECTED NAMESERVER CHANGENS changedsince last weekExpected?nobody said soAlarmimmediately, to two peopleBoth old and newin the messageUsuallya migration nobody mentionedNine times in ten it is a migration. The tenth is why it goes to two people.
Fig 2. How a nameserver change is handled. It is almost always benign and the response is sized for the case where it is not.
  • App integration
  • Machine learning
  • Networking
  • Management

Including both the old and new nameservers in the message is what makes it a ten-second triage. Somebody who moved the hosting recognises the new ones immediately; somebody who did not recognises that they do not, and that is exactly the distinction the message needs to support.

Next: the escalation, and who it actually goes to.

All posts