Who Holds the Front Door? A Domain and DNS Pre-Mortem for UK Cloud Teams

There is a line item on your invoice that costs less than a round of coffees and holds up everything else you run. It is not the compute. It is not the storage. It is the domain, the handful of nameservers behind it, and the chain of people who are supposed to remember to pay for both. Most UK cloud teams can talk you through multi-region failover at length. Ask them who owns the .co.uk and you will often get a pause.

So let us do the thing nobody schedules: a pre-mortem. Not "what could go wrong" in the abstract, but the specific, boring, entirely plausible sequence that takes you offline on a Saturday and leaves you explaining it on Monday.

Start with the worst Saturday of the year

Picture it. It is 02:10 on a Saturday. Your on-call engineer gets the alert — not a 500 from an application, but a flat nothing. Customers cannot resolve the site. Email bounces. The mobile app cannot reach its API. The status page is up because it lives on a different domain, which is small comfort to the person fielding messages from the sales director.

The team assumes a provider issue. Someone checks the dashboard. Everything is green. Then somebody has the good sense to run a whois lookup, and the answer is sitting there in plain text: the domain expired yesterday. The renewal reminder went to an inbox belonging to someone who left in March. The card on file was cancelled when the company swapped banks in 2024. The registrar has already parked the domain and started the grace-period clock.

That is the pre-mortem. The rest of this article is about how to make sure it stays fiction.

The registrar is a shop, not a department

A registrar is not a regulated utility. It is a business that sells you a lease on a name, and it will happily let that lease lapse if the payment fails and nobody raises a hand. For .co.uk names, the underlying register is Nominet, but your commercial relationship is with whoever sold you the name — and often that is a reseller, three layers deep, whose support email bounces.

Worth knowing: plenty of UK firms have domains registered through a defunct agency's account, with the registrar's contact address pointing at a domain that no longer resolves. That is not a misconfiguration. That is a hostage situation waiting to happen.

Things to check today

• Who is the registrant contact, and is it a person still at the company or a generic address someone monitors?
• Which card pays for the renewal, and does that card still exist?
• Is auto-renew on, and is there a second payment method?
• Are the registrar account credentials stored in a password manager the team controls, or in someone's head?
• For .uk names, has the registrant opted out of the right Nominet communications?

The agency that registered it in 2014

A familiar story: the domain was bought by a web agency when the site launched. The agency still holds the login, still pays the renewal, and invoices you for it annually. Then the agency restructures, the account manager moves on, and the new contact at the agency does not recognise your company name.

This is not a technology problem. It is a procurement and record-keeping problem, and it is worth resolving with the same seriousness you would apply to a supplier holding your production database.

Ask for registrar access, in writing, with a clear transfer plan. Do not accept "we'll manage it for you" as the final answer unless the contract makes them liable for lapses and gives you a documented break-glass route. The cheapest domain in your estate should not depend on someone else's inbox hygiene.

TTLs are the slowest undo button you own

Time-to-live values are the bit of DNS that everyone sets once and forgets. A TTL of 86,400 seconds means a record change takes up to 24 hours to settle across the internet. That is fine when you are moving a marketing page. It is not fine when you have discovered a bad record at 02:00 and need to roll back before the trading day starts.

Check your TTLs before you need them. Sensitive records — the apex, the API, anything a payment flow depends on — should sit at a value you are comfortable waiting out. If you have inherited a zone file with day-long TTLs and no documented rationale, that is not caution. That is a bet nobody consciously placed.

One provider, one nameserver set, one point of failure

Many teams have a primary DNS provider and a secondary listed in the zone, but no real secondary anywhere. Or they have two nameservers, both run by the same company, in the same region, behind the same login. That is redundancy in the way that owning two lottery tickets is diversification.

A proper secondary means a different provider, a different account, ideally a different organisation entirely, with a genuine zone transfer or API-synced copy and a documented process for switching to it. It should be tested. Not "we could, in theory" tested. Actually tested, in a window where nobody is on call for a real incident.

DNSSEC: half a lock is worse than none

DNSSEC is the bit people enable during a security review and then forget. That is the problem. DNSSEC adds a chain of cryptographic signatures. If the record set is signed but the delegation is broken — a stale DS record after a migration is the classic example — resolvers will refuse to answer. The domain does not become "less secure". It becomes unresolvable.

If you are running DNSSEC, you own it the way you own TLS certificates: with a calendar, a named person, and a check that the chain validates after any nameserver change. If you cannot commit to that, be honest about whether half a control is better than none.

The one-hour audit

You do not need a project. You need an hour, a shared document, and a willingness to be mildly embarrassed by what you find.

1. Pull the whois record and confirm the registrant, admin and technical contacts are current.
2. Log in to the registrar account and confirm the payment method and auto-renew status.
3. Trace every domain you own, including the ones bought for campaigns and the ones inherited in acquisitions.
4. List every nameserver set and note which provider runs each.
5. Check the TTLs on your most critical records.
6. Note where DNSSEC is enabled and who last validated the chain.
7. Write down what happens at 02:00 on a Saturday if a renewal fails, and who gets the call.

What done looks like

Done looks unglamorous. A named owner. A card that will not expire quietly. Registrar credentials in a managed vault. Two DNS providers that have actually been switched between. TTLs you chose rather than inherited. A line in the incident runbook that says, before you blame the cloud, check the front door.

The point of a pre-mortem is not to feel clever about the disaster. It is to notice that the cheapest thing you own is often the thing you understand least — and that the fix, today, costs less than an hour and a lot less than the explanation you would be writing on Monday morning.