Cloud & DevOps
Domain and DNS Setup That Won't Bite You Later
Key takeaway
Own the domain in the company's name with an account nobody personally controls, enable auto-renew and registrar lock, and put the renewal reminder on a monitored mailbox. Most domain disasters are administrative — an expired registration or an unreachable former employee — not technical.
Domains and DNS are set up once in an afternoon and then forgotten until something breaks spectacularly. A few decisions at the start prevent almost all of the common failures.
Ownership first
- Register in the company's legal name, with a company email address on a mailbox more than one person monitors — not a developer's personal account or an agency's.
- Enable auto-renew, keep a valid payment method on file, and check it annually. Expired domains are recoverable but expensive and slow.
- Turn on registrar lock to prevent unauthorised transfers, and enable multi-factor authentication on the registrar account.
- Keep the WHOIS contact reachable; it's how you'll be told about a dispute or a problem.
- Register the obvious variants and common misspellings if the brand matters, and redirect them to the canonical domain.
Records you'll actually use
- A and AAAA point a name at addresses; CNAME aliases one name to another, and cannot exist at the apex alongside other records — use your provider's alias record type for the root domain.
- MX for mail delivery, which must survive any web hosting change; separating DNS management from hosting is wise for exactly this reason.
- TXT records for domain verification and for email authentication — SPF, DKIM, and DMARC — which are what keep your mail out of spam folders.
- CAA to restrict which certificate authorities may issue certificates for your domain.
TTLs and change management
- Lower the TTL a day or two before a planned migration so the change propagates quickly, then raise it again afterwards.
- Remember that a low TTL only helps if you set it before the change, not during it.
- Keep an exported copy of the full zone. Rebuilding DNS from memory during an incident is a bad afternoon.
- Treat DNS changes with the same care as a deployment: reviewed, recorded, and reversible.
The failures worth monitoring
- Domain and certificate expiry, with alerts weeks in advance to a team address.
- Dangling records pointing at decommissioned services, which can be claimed by someone else — a real subdomain takeover risk.
- Nameserver reachability, ideally with providers in more than one network if the business depends on availability.
- Email authentication records after any change of mail or marketing provider, which is when they most often break silently.