Who holds your domain and where the site actually runs

A website stays online on two subscriptions bought in one order and renewed on two dates: the registration of the name, and the machine that answers for it. Neither announces that it is failing, and they fail differently. When hosting lapses the site disappears; when the registration lapses the site keeps running and nobody can reach it, which is more confusing and costs the address.

Why is the domain not the website?

A domain is a lease recorded in a registry, held through an intermediary, and paid for a year at a time. It is not a file or a machine: it is an entry saying that for the next twelve months this name resolves to whatever its nameservers say. The website is a program running somewhere, reachable because that entry points at it.

Between the two sits DNS, and this is where most confusion lives. The nameservers can be at the company that registered the name, at the company that hosts the site, or at a third party entirely. Changing host means changing DNS records; it does not mean the domain has moved, and moving the domain is a different operation with different paperwork.

What are the five things you are actually buying?

What it is	What it decides	What stops without it
Registration	That the name is yours to use	Reachability, after a grace period
DNS hosting	Where each name points	Everything that depends on the name
Web hosting	What the browser receives	The site, immediately
Certificate	Whether the browser trusts it	The padlock, then the page
Mail	Where the address delivers	Inbox, not website

Each line is a supplier, an account, a card and a date. Five lines bought from one company is not a mistake; it becomes one the moment nobody can say which invoice pays for which line.

What happens when a renewal fails?

The card on file expired, or the email that receives the renewal notice no longer exists, and the payment does not go through. Nothing visible happens for days. Then the registration enters a grace period, during which the name still resolves; then a redemption period, during which it can be recovered at a penalty; then it is released, and the first person who wants it can register it.

Meanwhile the site is running perfectly on a server nobody can reach. The report you receive is "the website is down", the first instinct is to call the host, and the host is innocent: the name stopped pointing anywhere.

The trap closes at the start: renewal notices go to the contact address on the registration, and that address is usually a mailbox on the same domain. When the domain lapses, so does the mailbox that would have warned you. Keep the contact address elsewhere, on a card that outlives any single employee.

Why is the transfer lock a feature?

Registrations carry a status that blocks transfer until the owner unlocks it and supplies an authorisation code. It exists because a stolen domain is worse than a stolen site: the attacker controls the name, the mail, and every password reset that arrives through it.

It protects you against someone with your login, and inconveniences you the day you want to move. The sequence is unlock, obtain the code, transfer, wait for propagation, and the lock is normally reapplied on the other side. Turning it off permanently, because it was in the way once, removes the only barrier between a stolen password and a stolen business address.

Who holds the certificate, and what does it prove?

A certificate binds the name to a key so the browser can tell the visitor they are talking to the site the address promises. It is issued for a fixed term and renewed automatically, which sounds like one problem solved until the renewal needs to prove control of the domain again — by serving a file or a DNS record — and something changed since: a proxy in front of the site, a moved nameserver, a redirect that swallows the file.

When renewal stops, the browser shows a warning before the content, and every visitor is told you are unsafe. The certificate is issued to a name, so it also breaks the day the name changes.

Where does the mail sit in all this?

Mail is the fifth line and the one most often forgotten in the inventory, because it does not look like part of the website. Its records live in DNS, which means whoever controls DNS controls where the mail goes — a detail that matters when a hosting migration includes "just point the nameservers at the new host" and quietly moves the mail with them.

A mailbox belongs to the company only if the company holds the account — a question of its own.

How do you write the inventory in one page?

1. List the five lines — registration, DNS, hosting, certificate, mail — and write the supplier next to each.
2. For each, note the account name, the email on it, and whose card pays. An account registered to a former employee is a line you do not control.
3. Write the renewal date and set a reminder thirty days earlier, on a calendar the company keeps, not an inbox.
4. Record how a change is made: the login, whether two-step verification is on, and where the recovery codes are.
5. Test one change a year — a DNS record, a redirect — and confirm it took effect.
6. Store the page where the company can read it without its author, and give a second person the means to act.

Contingency planning guidance would call this a dependency list with an owner; the exercise is the same whether the system is a website or a payroll service.

Where this goes wrong

• The registrar account is the web developer's, and three years later nobody can say whether the name renews.
• One card pays for everything, and when it expires five subscriptions lapse in the same week.
• The nameservers were moved during a redesign, and the mail was on the old ones.
• The renewal email is a mailbox on the domain that lapsed.
• The transfer lock was disabled after a migration and never turned back on.
• Nobody tested the certificate renewal after a proxy was added, and it failed quietly for a month.

What this does not cover

This is about who holds what and when it expires, not which supplier to choose: price, support quality and where the servers sit are commercial questions with answers that change. It does not cover moving a live site between hosts, which needs a plan for DNS time-to-live, a parallel copy and a rollback, nor migration of mail history, which is slower than the website and usually forgotten. How fast the site feels is a separate measurement — the Core Web Vitals guide defines what to measure there.

We set up hosting, DNS and certificates in the client's own accounts, hand over the credentials with the renewal dates written down, because a site you cannot move is not a site you own.