01What it asks, and where
Every name on the board is put to its own registry through this site’s WHOIS engine: RDAP where the ending has it, port-43 WHOIS where it does not, and DNS as the corroborating signal. The watchlist asks for the engine’s quick reading — the registry’s record and the nameservers — which it keeps for six hours, so a board of a hundred names does not cost the registries a hundred fresh questions every time the page is opened.
On opening, any name last read more than twelve hours ago is read again, two at a time and no faster than one every 1.6 seconds, which keeps well inside the engine’s limit of forty readings a minute. The ↻ key on a row asks that name’s registry afresh, past the cache. Each row says when its answer was read and from which protocol.
02The expiry date is the registry’s
The date on the board is the one the registry publishes, in UTC. For most generic endings it is not quite the date you have paid up to: when a .com reaches its expiry, Verisign renews it automatically and bills the registrar, so the published date can jump forward a year while the registrar is still deciding whether you are paying. Your registrar’s account is the authority on what you owe; the registry is the authority on what the record says, and the board shows the second.
Some registries publish no expiry at all. DENIC’s .de record carries the nameservers, a status and a last-changed date, and nothing else; the board files such names under No date rather than guessing one.
03The transfer lock
clientTransferProhibited is the registrar’s lock against a
transfer to another registrar. With it off, anyone holding the name’s
transfer code — the EPP or auth code — can start moving it, and a hijacked
registrar account or a phished code is how names are stolen. Unless you are
in the middle of moving a name yourself, it should be on, and the board says
so in red when it is not.
A registry lock is stronger: the three
server…Prohibited codes together, set by the registry, lifted only
by an out-of-band request. Some country-code registries publish no EPP codes
at all; for those the board says No lock codes, because
whether a lock is set cannot be read from outside.
04After the expiry
For generic endings the timetable is written into ICANN’s registry agreements. The dates the board shows under each such name are computed from it, and they are estimates, because the first step is the registrar’s choice:
| Stage | How long | Who can act |
|---|---|---|
| Auto-renew grace | 0 to 45 days | The holder, through the registrar — how many days is the registrar’s call. |
| Redemption | 30 days | The last holder only, with a restore fee. |
| Pending delete | 5 days | Nobody. |
| Released | after that | Whoever registers it first. |
Country-code registries set their own rules — some delete on the day, some hold a name for months — and publish no timetable, so for them the board draws no grace or release dates at all. To watch a name you do not hold on its way out, use the drop watch.
05The calendar file
Calendar .ics writes one standard iCalendar file (RFC 5545):
an all-day event on each name’s expiry date — the UTC date the registry
publishes — with three reminders, 60, 30 and 7 days before. Each event carries
a fixed identifier, <name>-expiry@domainchaos.com, so importing
a newer file updates the dates in most calendar applications rather than
duplicating them. The description names the registrar and links the full
WHOIS record. Names with no published expiry are left out, and the page says
which.
06What is kept, and where
The list lives in this browser’s own storage and nowhere else: no account, no server copy, nothing to sync. Each name travels to the WHOIS engine on its own, exactly as a single lookup does, and the engine keeps its answer in its cache and nothing more. Clearing the browser’s data clears the list, so the JSON export is the backup — paste it back into the import tray and every name comes back. The CSV is for a spreadsheet, and no value from a registry can become a formula in it.