Most people open their domain’s DNS settings once, under duress, while changing providers, and never again. But a good share of “the website is down” incidents originate there, and they are unusually hard to diagnose, because nothing is wrong with the website.
Here are the record types you will meet, explained well enough to read your own configuration and to judge whether what someone is asking you to change makes sense.
What DNS is for
Domains are for people; servers are found by IP address. DNS is the directory in between: someone types your domain, DNS says which IP to go to.
The important property is that this directory is distributed and cached. Change a record and the world does not learn immediately — servers everywhere still hold the previous answer until it expires. That is why DNS changes “take time to propagate”.
A record: which server the domain points to
The basic one. An A record points a domain at an IP address.
example.co.nz A 203.0.113.10
Meaning: for example.co.nz, go to the server at 203.0.113.10.
When you change it: moving hosting. The new provider gives you an IP and the A record moves to it.
CNAME: this name follows another name
A CNAME points not at an IP but at another domain.
www.example.co.nz CNAME example.co.nz
Meaning: the www version follows the bare domain wherever it goes.
Why use it: if the server’s IP changes you edit one A record and everything pointing at it by CNAME follows. Hosting platforms usually ask for a CNAME precisely because their IPs change.
One limitation: the root domain — example.co.nz with no prefix — cannot use CNAME under the standard. Many providers offer a workaround called ALIAS or ANAME with the same effect. Without one, the root has to use an A record.
MX: where email is delivered
MX records decide which server receives mail addressed to @example.co.nz.
This is where the worst accidents happen, because it is entirely independent of the website while people assume everything about a domain moves together.
The classic incident: moving web hosting, clearing the DNS records to reconfigure cleanly, setting up the A record and forgetting MX. The website loads, everything appears to have worked — and from that moment every email to the company bounces, with no indication whatsoever. Senders get failure notices, you receive nothing, and some days later a customer rings to ask why their email went unanswered.
Practical rule: export or screenshot every existing record before changing anything. Old-fashioned, and the only way back from this class of mistake.
TXT: notes for machines
TXT records hold plain text, mostly for three purposes:
Proving the domain is yours. Google Search Console and many services verify ownership by asking you to add a TXT record with specific content. It can be removed afterwards, though keeping it saves repeating the exercise.
Email authentication — SPF, DKIM, DMARC. These declare which servers may send mail using your domain. Missing or wrong, your outgoing mail is more likely to be filtered as spam. Anyone using an email marketing tool needs them.
The detail here is specialised, but one heuristic is useful: if customers regularly say they did not receive your emails, check these records first.
TTL: how long a record may be cached
Every record carries a TTL in seconds — how long other servers may keep the answer.
Defaults are typically 3600 (an hour) or longer. Longer means fewer lookups, which is good, and slower propagation of changes, which is not.
Useful technique: a day or two before a planned server move, lower the TTL on the relevant records to 300 seconds. The actual switch then propagates worldwide in minutes rather than hours. Raise it again once things are stable.
A small action that turns “some users cannot reach the site for two hours after the switch” into “everyone moved within five minutes”.
Why a change appears not to work
The most common confusion. Likely causes in order:
Still within the TTL. Servers elsewhere hold the old answer. Waiting is the fix, and the wait is the previous record’s TTL.
Your own machine’s cache. Operating systems and browsers both cache. Test from another network — mobile data will do. Correct there means the stale copy is local to you.
Editing the wrong place. A domain may be managed at its registrar, or DNS may have been delegated elsewhere, to Cloudflare for instance. Editing at the registrar then achieves nothing, because the delegated provider is authoritative. Confirm who currently manages your DNS first — getting this wrong wastes a great deal of time.
How to check: dig yourdomain on Mac or Linux, nslookup yourdomain on Windows, shows what is actually resolving right now. Far more reliable than refreshing a browser.
What changes once a CDN is in front
With Cloudflare or similar, DNS is managed there and each record gains a proxy toggle.
Proxy on: the domain resolves to Cloudflare’s IPs and traffic passes through it, which is what enables caching and protection and hides your server’s address.
Proxy off: the record returns your server’s real IP and Cloudflare acts only as DNS.
Some records must have the proxy off, mail-related ones especially. Proxy your mail server record and email stops working entirely, because the proxy handles web traffic only. This is the most common incident immediately after adopting Cloudflare.
Three practical rules
Export before editing. Most DNS panels export; screenshot if yours does not. When something breaks you need to know what it looked like.
Change one thing at a time. Five simultaneous edits leave you unable to say which broke it.
Verify with dig rather than a browser. Browsers cache and will mislead you.
When we take on a project we record every existing DNS entry before touching anything, including those unrelated to the website. Not excessive caution — email going dark is typically noticed days later, and the enquiries lost in between do not come back.