DNS records explained: a plain-English guide for Australian domain owners

DNS is one of those things that sits quietly in the background until the day you need to change it — and then it suddenly matters a great deal. A new email provider wants you to add some records. Your web developer asks you to "repoint the domain". A migration goes sideways and everyone's staring at a screen wondering why the site still loads the old server.

None of this is complicated once you understand what a DNS record is and what the common types do. This guide walks through them in plain English, with the practical detail that actually matters when you're the one making the change.

What DNS actually is

Every device on the internet is reachable by an IP address — a string of numbers like 203.0.113.10. Computers are perfectly happy with those. People are not. DNS, the Domain Name System, is the layer that lets you type dswebhosting.net.au instead of memorising a number.

The usual analogy is a phone book: you look up a name, you get back a number. That's close enough to start with, but it undersells what's happening. DNS isn't one big book — it's a distributed, hierarchical lookup that happens in milliseconds, every time anything on the internet needs to find anything else. When you load a website, send an email, or your phone checks for app updates, DNS lookups are happening constantly underneath.

The key thing to hold onto: your domain's DNS records are a set of instructions. They tell the rest of the internet where to send web traffic, where to deliver your email, and how to verify things that claim to come from you. Get them right and everything just works. Get one wrong and a specific thing breaks — often in a way that looks mysterious until you know where to look.

Where DNS records actually live

Before the record types, it helps to know where these settings are kept, because this is where a lot of confusion starts.

Your domain has a set of authoritative nameservers — the servers that hold the official answer for your domain's records. Whoever runs those nameservers controls your DNS. That might be your registrar, your hosting provider, or a third-party DNS service. When you edit DNS records, you're editing them wherever the nameservers point.

This catches people out constantly: they log into one control panel, change a record, and nothing happens — because their nameservers are actually pointed somewhere else entirely, and they've just edited a copy that nothing is reading. The first question to answer for any DNS task is always: where are this domain's nameservers, and am I editing records in the right place?

The records you'll actually touch

There are dozens of DNS record types in the wild, but in practice you'll only ever deal with a handful. These are the ones worth knowing.

A record — points a name at an IPv4 address

The workhorse. An A record maps a hostname to an IPv4 address. When you point www.yourbusiness.com.au at your web server, you're setting an A record.

The @ symbol is shorthand for "the bare domain" (e.g. yourbusiness.com.au with no prefix). If your site needs to work both with and without the www, you typically need both records — or an A record for the bare domain and a CNAME for www (more on that shortly).

AAAA record — the same thing, for IPv6

An AAAA record (spoken "quad-A") does exactly what an A record does, but for an IPv6 address — the newer, much longer addressing scheme that looks like 2001:db8::1. If your host supports IPv6, you'll have both an A and an AAAA record pointing at the same server. If you've never knowingly dealt with IPv6, it's almost certainly being handled for you, and you can leave it alone.

CNAME record — points a name at another name

A CNAME (Canonical Name) record is an alias. Instead of pointing at an IP address, it points at another hostname. This is genuinely useful: if www is a CNAME pointing at your bare domain, then whenever the server's IP changes you only update the A record on the bare domain, and www follows automatically.

MX record — where your email goes

An MX (Mail Exchange) record tells the rest of the internet which servers handle email for your domain. When someone emails you@yourbusiness.com.au, their mail server looks up your MX records to know where to deliver it.

MX records have a priority number — lower numbers are tried first. This lets you have a primary mail server and a backup that only receives mail if the primary is unreachable.

The most common email outage I see has the same cause: someone changed hosting, the new host helpfully set up "default" MX records pointing at its own mail service, and the business's real email (often Microsoft 365 or Google Workspace) silently stopped arriving. If you move hosts, check your MX records still point at your actual email provider before you assume the migration went cleanly.

TXT record — free-form text, used for verification and email security

A TXT record holds arbitrary text. On its own that sounds useless, but it's become one of the most important record types because of what people put in it. Two big uses:

• Domain verification. When Google, Microsoft, or some SaaS tool asks you to "prove you own the domain", they usually hand you a TXT record to add. They then look it up to confirm you control the DNS.
• Email authentication. SPF, DKIM and DMARC — the records that stop spammers forging email from your domain and that keep your legitimate mail out of spam folders — are all published as TXT records.

Email authentication is important enough, and fiddly enough, that I've written it up separately rather than cramming it in here. If you're setting up or troubleshooting email deliverability, start there: SPF, DKIM and DMARC explained.

NS records — who holds the answers

NS (Nameserver) records declare which nameservers are authoritative for the domain. You generally set these at your registrar, and changing them hands DNS control to a different provider. You won't touch these often, but they're the reason the "am I editing in the right place?" question matters — the NS records are what decide which place is the right one.

SOA record — the housekeeping one

Every zone has exactly one SOA (Start of Authority) record. It holds administrative metadata — the primary nameserver, a contact address, and the timers that control how secondary servers and caches refresh. You almost never edit it by hand; it's listed here so it's not a mystery when you see it.

TTL and "propagation": the 48-hour myth

Every record has a TTL (Time To Live), measured in seconds. It tells servers around the internet how long they're allowed to cache the answer before checking again. A TTL of 3600 means "you can remember this for an hour".

This is the entire mechanism behind what people call "DNS propagation". When you change a record, the new value is live on your authoritative nameservers almost immediately. But anyone who looked it up recently is holding a cached copy until its TTL expires. There's no wave of changes slowly rolling across the globe — just caches quietly expiring at different times.

The practical upshot:

• The old "allow 24 to 48 hours" advice is mostly a safety margin from a slower era. Most changes are visible to most people within minutes to an hour or two.
• If you know a change is coming — a host migration, for example — lower the TTL on the relevant records a day or two beforehand (say to 300 seconds). Then when you make the actual switch, caches expire in five minutes rather than hours, and the cutover is nearly instant.
• After the change has settled, you can raise the TTL back up to reduce lookup load.

A quick reference

If in doubt, ask before you change

DNS is forgiving in one sense — nearly every change is reversible — but unforgiving in another: a wrong MX record can quietly lose email, and you might not notice for hours. If you're staring at a control panel unsure whether you're about to break something, that's a perfectly good moment to get a second opinion before you hit save.