DNS records

DNS records are the settings that turn your domain into a location. When somebody types your address, their device asks the domain name system where to go, and these records are the answer it gets back. They decide which server serves your pages, which provider receives your mail, and which outside services are allowed to act on your behalf. They are a handful of short lines of text, and getting one of them wrong takes the website and the email down together.

In short

• DNS is the internet’s address book and these records are your entry in it.
• The same set of records controls both your website and your email.
• Changes are not instant, because old answers are cached until they expire.
• Whoever your nameservers point at is who actually holds the records.

What DNS is doing

Computers do not find each other by name. They find each other by number, and your domain has to be translated into one every time somebody visits.

That translation happens in stages. A visitor’s phone asks its network, the network asks a resolver, the resolver works its way from the root of the system down to the servers responsible for your domain, and those servers read out your records. The whole exchange finishes in a fraction of a second and repeats millions of times a day for a busy site.

The practical consequence is this. Nothing about your website is stored in DNS. DNS only ever answers the question of where to look, which is why a domain can be perfectly registered, a server perfectly healthy, and the site still entirely unreachable.

Where your records actually live

This is the part that wastes the most time on support calls. Three companies may be involved and only one of them holds the records.

• Your registrar holds the domain and the nameserver setting.
• The nameservers named in that setting are the servers that answer for your domain. Whoever runs them holds the zone.
• Your host runs the site, and may or may not be the same company as the above.

So the first question is never what your records say. It is which nameservers your domain points at. Answer that and you know which login to open. Editing records at a registrar whose nameservers are not in use is a change that appears to save and then does nothing at all, which is a genuinely miserable half hour.

The DNS records you will meet

A small business zone has perhaps a dozen entries. These are the ones worth recognising.

• A record. Points a name at an IPv4 address. This is what usually sends yourbusiness.ph to your server.
• AAAA record. The same thing for the newer IPv6 addresses.
• CNAME record. Points one name at another name rather than at an address, which is how shop.yourbusiness.ph follows whatever platform is running behind it.
• MX record. Says which servers receive mail for the domain. Listed with priority numbers, where the lower number is tried first.
• TXT record. Free text, used for proof rather than routing. Email authentication and the verification strings from Google, Meta and payment providers all live here.
• NS record. Names the servers responsible for the domain.
• CAA record. Lists which certificate authorities are permitted to issue an SSL certificate for the domain.

Each record also has a name, which is either the bare domain or something in front of it, and a TTL.

TTL, and why nothing is instant

TTL stands for time to live, and it is a number of seconds attached to every record. It tells anyone who looks the record up how long they are allowed to reuse the answer before asking again.

This is why a change you made ten minutes ago is live on your phone and not on your office network. The office network asked earlier, was told the answer was good for four hours, and is dutifully serving the old one. Nobody is transmitting anything. Copies of the previous answer are simply expiring at different times in different places, which is what people mean when they say propagation.

The useful habit around a planned move is to lower the TTL to a few minutes about a day in advance, make the change, confirm it works, and then set it back. A low TTL during a migration turns a mistake into a five minute problem instead of a half day one.

The records that keep your email alive

The DNS emergencies that actually hurt a small business are usually email emergencies, and they are all preventable.

Your MX records decide who receives mail for the domain. Change your website’s hosting without carrying the MX records across and mail simply stops, without an error anyone in your office can see. The sender gets a bounce. You get silence. It is the most common casualty of a migration done in a hurry, and the reason email hosting is worth treating as a job of its own rather than an afterthought of the website move.

Three text records decide whether the mail you send is believed.

• SPF lists which servers are allowed to send mail for your domain.
• DKIM attaches a signature that proves a message was not altered.
• DMARC tells receiving providers what to do when a message fails the other two, and can send you a report on who is trying.

Without them your invoices and quotes are more likely to be filed as spam, and anyone who wants to send mail pretending to be you has an easier time of it. The same three records are the foundation of email deliverability for anything you send in bulk.

What goes wrong, and how it looks

DNS faults are recognisable once you have seen each one.

• Site not found at all, on every device. Usually the domain, the nameservers, or a deleted A record. The server is normally fine.
• Works with the www, fails without it, or the other way round. One of the two names has no record.
• Site fine, email dead. The MX records were lost, almost always during a migration.
• Security warning on a working site. Usually the SSL certificate rather than DNS, though a CAA record can stop a new one being issued at all.
• Live for you, broken for a colleague. Caching. Wait for the TTL.

Before you change anything

DNS is unusual in that a five second edit can take a business offline and there is no undo button in most control panels.

1. Export the zone first. Most providers offer a download. It is your only copy of what worked.
2. Change one record at a time and confirm each one before the next.
3. Check the mail records specifically after any move, by sending a message to the domain from an outside account.
4. Lower the TTL a day ahead of anything planned.
5. Leave records you do not understand alone. The unexplained string is usually holding a verification together.

If you use a maintenance arrangement, this is the sort of thing it should cover, alongside the hosting itself. It is a small amount of work that only matters on the day it matters.