Handing a domain to the next committee

The handover that fails

The pattern is familiar to anybody who has served on a committee. A member who looked after the website for years steps down, is thanked warmly, and hands over a laptop, a folder and a verbal assurance that everything is in the email. Eighteen months later the site needs a change, or a renewal notice bounces, and the new committee discovers it does not know which company holds the name, which account it sits in, or which of four old addresses receives the notices. The former member has moved, or has forgotten, or is happy to help but cannot remember a password set six years ago.

Nothing was hidden and nobody behaved badly. The handover simply covered the visible work, the website and the newsletter, and not the invisible arrangements underneath it.

What is actually being handed over

A domain arrives with a cluster of related things, and each of them can sit at a different company. There is the registration itself, held at a registrar in an account with its own login. There is the DNS service, which may be the registrar or may not. There is the website hosting. There is the email, which may be a separate provider again. And there are the recovery routes into each of those accounts, which are frequently pointed at the outgoing volunteer's personal mailbox or phone.

Handing over a website password while leaving those five arrangements undocumented is the commonest version of the failure. The website is the least critical of the five, since a site can be rebuilt from scratch. The domain cannot be recreated by effort alone.

The written record

The remedy is a short document, kept with the constitution and the insurance papers rather than on the departing member's laptop. It does not need to contain passwords, and in most cases it should not. It needs to say where things are, so that a successor can prove entitlement and be let in.

1. The domain names held, all of them, including redirects and old names nobody uses.
2. The registrar for each, by company name, with the address of the account login page.
3. The account holder and the contact mailbox on each account, so a successor knows which address the recovery messages will reach.
4. The registrant of record, and whether it names the organisation or an individual.
5. The expiry date and how the renewal is paid, whether by card, mandate or invoice, and in whose name.
6. Where DNS is managed, which is often not where the name is registered.
7. Where the website and the email are hosted, with the same account details for each.
8. Anything unusual, such as a supplier who technically holds the name or a service that depends on a particular record staying in place.

That list, filled in, converts a mystery into an errand. It is expanded with a line of context per item in the handover checklist.

Recovery addresses that outlive the person

The single most valuable change a committee can make is to point account recovery at something that survives turnover. A role based mailbox read by two officers, hosted somewhere other than the organisation's own domain, does the job. Two factor authentication tied to one person's phone is the modern version of the old problem, and where it is used, backup codes belong in the same place as the constitution rather than in a wallet.

Passwords change harmlessly. A recovery address that belongs to somebody who has left is what turns a small problem into a lost name.

Doing it before the resignation, not after

Handover is easiest while the outgoing person is still involved and still cares. The moment to ask is when someone takes the role, not when they leave it: agreeing at the start that the record will be kept in the organisation's name, in a shared account, removes the awkwardness of asking a departing friend to prove they are not hoarding something. Reviewing the sheet annually alongside the accounts keeps it true, and means no single handover carries the whole burden.

When nothing was written down

Reconstruction is usually possible. A public lookup on the name gives the registrar, the expiry date and the current status, as described in WHOIS and RDAP. The nameservers on the record point to whoever runs the DNS. Bank statements identify who has been paying and to which company. From there the registrar can be approached with evidence of the organisation's entitlement, along the lines set out in who owns a domain. It takes weeks rather than minutes, which is the argument for writing it down the first time.