DNS explained: the part that breaks at the worst moment

DNS is the internet's address book. It turns a name people can remember into a number machines can route to, and it does this several billion times a second without anyone thinking about it.

It is also, reliably, what has gone wrong when a website vanishes for no apparent reason or email stops arriving overnight. Worth understanding at the level of “what are these records and which one did we just change”.

The records you will actually meet

A record — points a name at an IPv4 address. yourdomain.co.uk → 203.0.113.10. This is the one that says where your website lives. (AAAA is the same thing for IPv6.)

CNAME — points a name at another name. www.yourdomain.co.uk → yourdomain.co.uk. Useful because if the underlying address changes you only update it in one place. Most modern platforms hand you a CNAME rather than an IP address for exactly this reason.

MX — where email for your domain should be delivered. Get this wrong and your website is completely fine while your email silently stops.

TXT — free-form text, used for verification and email authentication. Your SPF, DKIM and DMARC records live here, and so does the Google Search Console verification if you use that method. There is a whole article on why those matter now: why your email stopped arriving.

NS — which nameservers are authoritative for your domain. This is the master switch. Change it and you change which DNS provider answers for everything at once.

The one that catches people: TTL

Every record carries a time to live — how long resolvers around the world are allowed to remember the answer before asking again.

A TTL of 86400 means one day. So if you change a record with a day-long TTL, some people will keep getting the old answer for up to a day, entirely correctly.

This is the mechanism behind “propagation”, and the word does the concept a disservice. Nothing propagates. Nothing is spreading across the internet. Caches are simply expiring at different times depending on when each one last asked.

Which leads to the single most useful DNS tip in this article:

Before a planned change, lower the TTL first. Drop it to 300 seconds, wait for the old TTL to expire, then make your change. It now takes five minutes to take effect everywhere instead of a day. Put the TTL back afterwards.

Nobody tells you this and it turns the most stressful part of a website move into a non-event. More on that in moving a website without downtime.

Where your DNS is managed

Three common places, and knowing which is yours saves an hour of confusion:

• At your registrar — the default. Convenient, and the interfaces vary from fine to genuinely hostile.
• At your host — common when a host sets everything up for you. The catch is that leaving the host means moving DNS too.
• At a dedicated DNS provider — the setup we would generally recommend. Faster, better tooling, and it decouples DNS from both your registrar and your host, so changing either is a smaller job.

The NS records decide which of these is actually in charge. If you are editing records somewhere and nothing is happening, it is almost always because the NS records point somewhere else and you are editing a file nobody reads.

The four failures we see most

1. Editing DNS at the wrong provider. As above. Check the NS records first, every time.
2. Changing nameservers without copying the records across. The new provider starts with a blank sheet — and if you had MX records, your email stops instantly. Copy everything before switching, not after.
3. Two SPF records. The specification allows exactly one. Adding a second when you add a new mail service does not extend it; it invalidates both.
4. The forgotten subdomain. An old mail. or shop. record still pointing at a server that no longer belongs to you. At best dead, at worst someone else's.

A ten-minute audit

Worth doing once a year, and now is as good a time as any:

• Find where your DNS is actually managed — check the NS records.
• List every record. Anything you cannot explain, investigate rather than delete.
• Confirm your MX records point where your email actually is.
• Check you have exactly one SPF record, and that it lists every service that sends on your behalf.
• Remove subdomains pointing at things you no longer run.
• Save a copy of the whole zone somewhere outside the provider. Ten minutes now, hours saved if an account is ever lost.

Why this is worth your attention

DNS is small, boring, and controls whether anybody can reach you at all. It is also the layer where a five-minute mistake causes a day-long outage, purely because of caching — which is precisely why understanding TTL is worth more than understanding anything else here.

If you want someone to go through your zone with you and explain what each record does, that is a normal part of a free call. See also what a domain actually is and locking your domain down.