The address book analogy

DNS runs every website visit you have ever made, and almost nobody can explain it at a dinner table. One analogy carries the whole thing: it is the internet's address book — and you are allowed to edit your own entry.

Computers find each other by IP address — strings like 203.0.113.42 that nobody wants to remember. DNS is the lookup layer between the names humans use and the addresses machines need: type yoursite.co.uk, and your browser quietly asks the address book where that actually is before connecting.

The part that makes DNS feel mysterious is that there is no single book. Your ISP keeps a copy, big public resolvers keep copies, and every copy caches answers for a while so the system stays fast. Understanding that it is many cached copies of your entry explains almost every confusing behaviour DNS has — including why changes take time to show up everywhere, which we will get to.

Who holds the master copy? Whichever servers your domain's nameservers point at. When you “point your domain at a host”, you are telling the world's resolvers which servers hold the authoritative answers for your name. Change nameservers and you change who answers; everything else in this article lives inside those answers.

A records: where the website lives

The A record is the fundamental one: this name maps to this IPv4 address. When yoursite.co.uk has an A record of 203.0.113.42, browsers connect to that server and ask it for the site. Its sibling, the AAAA record, does the same job for IPv6 addresses — hosts that support IPv6 publish both, and browsers use whichever connects first.

You will usually have at least two: one for the bare domain and one for www. If your host manages your DNS — the normal arrangement once nameservers point at them — these exist automatically and you rarely touch them. The time you do touch an A record is the interesting one: moving hosts, where editing this single line is the actual moment of switchover.

CNAME records: aliases

A CNAME says this name is another name — look that one up instead. www.yoursite.co.uk is very often a CNAME pointing at yoursite.co.uk, so that when the site's address changes, one A record update covers both.

They are also how third-party services attach to your domain: a newsletter tool or a status page will ask you to create status.yoursite.co.uk as a CNAME to some name they control, so they can move their infrastructure without ever bothering you again. Two rules keep CNAMEs out of trouble: the bare domain itself cannot be one (a technical restriction of the standard), and a name that is a CNAME cannot also hold other records — which is why email breaks when someone CNAMEs a name that carried MX records.

MX records: where email goes

Web traffic and email are separately routable, and MX records are why. An MX record answers one question: which server accepts mail for this domain? The number beside each entry is a priority — lowest wins, and the others are fallbacks.

This separation is genuinely useful: your website can live at your host while your email lives at Google Workspace, or vice versa, purely by pointing MX somewhere different from the A record. It is also the number one cause of “my website works but email vanished”: if you manage DNS somewhere other than your host — commonly Cloudflare — and forget to carry the MX records over, the web keeps working while mail bounces. Whenever you change DNS setups, check MX first.

TXT records: the domain's noticeboard

TXT records hold arbitrary text, which sounds useless until you see what the internet built on them. Verification (“paste this TXT record to prove you control the domain” — Google, Microsoft and half of SaaS onboarding). And crucially, email authentication: SPF lists the servers allowed to send as your domain, DKIM publishes the key that verifies your mail wasn't forged, and DMARC tells receivers what to do when those checks fail.

Those three records are the difference between your messages arriving and landing in spam, and the large providers now effectively require them. The full setup is covered in the domain email guide; the point here is simply that they are all just TXT records — text on your domain's noticeboard that receiving servers know to read.

Propagation, TTLs, and why changes 'take 48 hours'

Back to the many cached copies. Every record carries a TTL — time to live — telling resolvers how long they may keep an answer before asking again. Change a record with a 24-hour TTL and some visitors keep getting the old answer for up to a day. That is all “propagation” is: caches expiring on their own schedules. Nothing is spreading through the internet; the internet is just finishing its coffee.

Which yields the one professional trick worth knowing: lower the TTL before a planned change, not after. Drop it to 300 seconds a day in advance, make your change, and the world catches up in minutes. Raise it back to an hour afterwards so resolvers aren't asking constantly. Do this before a host move and the folklore 48 hours becomes five minutes.

When something misbehaves, check what resolvers actually see rather than guessing: any online DNS lookup tool will show your records from multiple locations, and the answer usually diagnoses itself — a stale cache, a typo'd address, or the MX records someone forgot to copy. The DirectAdmin DNS editor guide shows where each record lives in the panel.