You’ve migrated a site to a new host on a Friday, and by Monday the pages load but your email has stopped arriving. Between the domain name you pay for annually (sometimes longer) and the server hosting your site, a short list of text entries decides where every visitor and every email goes, by mapping or pointing those names to an address. Most explanations of DNS reach for a phonebook analogy which, while accurate, is not much use at four on a Friday afternoon.
What DNS does when someone types your address
Every server on the internet has a numeric IP address, but people remember words, not numbers, and especially not numbers in IPv6 format. So the Domain Name System (DNS) sits between the two as a translation layer. When a customer types your domain into a browser, their internet service provider asks a chain of servers which machine holds the site. It starts at a root nameserver, which sends it on to the server for your top-level domain. That one then names the authoritative server publishing your records.
The answer is held on the way. Your browser keeps a copy, your computer holds one, and your provider’s DNS resolver holds one for everyone on its network. This DNS cache is why a site loads faster the second time you visit, and it’s also why a change you made an hour ago is live for you but invisible to a colleague on a different network.
The records a small business touches
A DNS zone is the file holding every record for a domain, and most of it never needs your attention. Four kinds of record account for nearly everything a small business needs to keep an eye on when changing providers or altering records.
An A record points a name at the IP address of a server. Your bare domain and your www name each need one, and when you move host this is the record that moves with you. A CNAME record points one name at another name instead of at an address, which suits a subdomain such as shop.yourbusiness.co.uk that should follow the main name wherever it goes.
An MX record points to the servers that take email for your domain. Each has a preference number, and the lowest one is tried first. By using the preference numbers you can set up backup servers that handle email even when the primary server is down. A TXT record stores plain text for other systems to read. This includes the SPF and DKIM records that are vital for mail delivery, with DMARC under its own _dmarc name. If you use Google or Microsoft mail services, they’ll also ask you to add a TXT record to demonstrate that you own the domain.
Type out the entries provided by your other service character by character. A single mistake in an SPF or DMARC record won’t trigger an error, but it will adversely affect how mail servers handle your messages, and you’ll only notice when a customer complains their invoice ended up in junk. Our KB covers setting up a DMARC record in cPanel and many other DNS-related topics, so be sure to check it out.
Who holds your DNS and who can change it
Three players can be involved in a single domain, and that’s where things might get confusing. There’s the registrar who sold you the name, the registry that manages the top-level domain (Nominet, for anything ending in .uk), and the authoritative nameservers that publish your records.
Your nameservers are set at the registrar, and they point at whoever hosts your zone. Where a domain uses our nameservers, the records live in your hosting control panel, and our KB guides walk through managing your nameservers and editing your DNS zone. Registering through us puts the name and the zone behind one login, which is the practical argument for buying domain names from the company already running the server, as it’s simpler to maintain.
Always remember to make a backup of your DNS zone before editing.
What breaks when a record is wrong
DNS faults break along clean lines, so the symptom usually tells you which record to open. A website that fails to load anywhere points at the A record or at the nameservers. Email that sends fine but never arrives points at the MX records, and messages that arrive but land in junk point at SPF or DMARC.
Also, a side note most people overlook: certificates. For an SSL/TLS certificate to be issued, the name must resolve to the server making the request. If an A record still points to an old host, it will block the certificate request long before anyone notices the missing padlock.
How long a change takes to apply
Each record has a set lifetime, a number in seconds that tells resolvers how long they can keep the answer before asking again. This is called the TTL, or time to live, and the DNS specification, RFC 1035, defines it exactly that way. The TTL accounts for the whole of what people call propagation. What this means is that the TTL holds the cards. Nothing goes out across the internet when you save a record, and the old copies expire on their own clock.
Following on from that, it helps to drop the TTL on a record a day before you plan to change it, then raise it again once the new value is live. If you’re waiting on a change now, our KB covers checking DNS propagation and flushing the resolver cache on your own machine, which is often all that stands between you and an updated record.
DNS is a small amount of text doing a large amount of work, and it feels obscure because, even though it’s used daily, most people never interact with it directly. Once you know which record answers which symptom, it becomes routine maintenance. Check who controls the nameservers for your domain before your next renewal, and whether you can access the zone directly. If it’s a bit of a faff, shift the registration while things are still running smoothly. The domain names page is the place to start.
