DNS for people who deploy things

DNS is one of those systems that works invisibly until it does not, at which point the failure is confusing because the symptoms appear somewhere else entirely. “The site is down for some users but not others” is nearly always DNS, and so is “it worked when I tested it”.

You do not need to understand the protocol. You do need to understand caching, a handful of record types, and how delegation works.

The record types you will actually use

A maps a name to an IPv4 address. AAAA does the same for IPv6. Publish both if your infrastructure supports both.

CNAME aliases one name to another name. The critical restriction: a CNAME cannot coexist with other records at the same name, which is why you cannot put a CNAME at the root of a domain. Many providers offer a proprietary flattened alias record to work around this.

MX directs mail. Lower priority numbers are preferred. If you use a hosted mail provider, these are theirs, and deleting them because they looked unfamiliar is a genuinely common way to lose mail.

TXT holds arbitrary text, used for domain verification and for the mail authentication records: SPF, DKIM and DMARC.

NS delegates a zone to a set of nameservers. These determine who is authoritative.

CAA restricts which certificate authorities may issue certificates for your domain. Cheap to set and worth doing.

Time to live, which causes most of the pain

Every record carries a TTL telling resolvers how long they may cache the answer. That number determines how long a change takes to become universally visible.

Three consequences follow, and they account for most DNS-related incidents.

A change is not instant. If the TTL is a day, some resolvers will serve the old value for up to a day after you change it. Nothing you do speeds this up, because the old value is already cached elsewhere.

Lower the TTL before the change, not during it. To migrate with a five-minute cutover, set the TTL to five minutes at least one full old-TTL period beforehand. Lowering it at the moment of the change does nothing, because the long-lived old value is already out there.

Raise it again afterwards. A permanently short TTL means more lookups, marginally more latency, and a harder failure if your DNS provider has trouble.

A practical pattern: keep TTLs at an hour normally, drop to five minutes a day before a planned migration, migrate, verify, then raise them again a day later.

Delegation, and why the registrar matters

Your registrar holds the nameserver records that say who is authoritative for your domain. Whoever those nameservers point to serves your records.

Two failure modes recur.

Editing records at the wrong provider. If your nameservers point to a cloud provider’s DNS but you edit records in the registrar’s control panel, nothing happens, and it looks like a caching problem. Confirm which provider is actually authoritative before debugging anything else.

Nobody has access to the registrar. Domain registration is often bought by whoever was around at the time and never handed over. Discovering this during an urgent change is a bad afternoon. Check now who controls the domain and who receives the renewal notices.

Domain expiry, incidentally, is a leading cause of unplanned outages at small organisations. Enable auto-renew and make sure the contact address is a role rather than an individual who may have left.

Debugging in a useful order

When something looks like DNS, resolve in this order rather than guessing.

1. Query the authoritative nameserver directly to see what is actually published. If it is wrong there, the change did not take effect or was made in the wrong place.
2. Query a public resolver to see what the wider internet is being told. A difference between this and the authoritative answer means caching, and you wait.
3. Query from the affected machine, because it may use a different resolver, or have an entry in a local hosts file, or be running its own caching daemon.
4. Check propagation from several locations using an online tool, which shows whether the change has reached different networks.

Most “DNS is broken” reports resolve at step one or step three.

Mail records, which are easy to break

If your domain sends mail, three TXT records matter and misconfiguring them causes mail to be silently discarded.

SPF lists which servers may send on your behalf. There is a hard limit on the number of lookups an SPF record may cause, and exceeding it makes the record fail entirely rather than degrade. Adding a fourth or fifth service to an existing record is exactly how this happens.

DKIM publishes the public key that signs your outgoing mail.

DMARC tells receiving servers what to do with mail that fails the other two, and where to send reports.

If you use a hosted mail provider, take their published values rather than composing your own, and change them only when they tell you to.

Practical habits

Keep records in version control if your provider supports an API or a zone file export. A record deleted by accident is much easier to restore from a diff than from memory.

Prefer CNAME to A for third-party services, so that when they change their addresses your record keeps working.

Set CAA records to restrict certificate issuance to the authorities you use.

Document your zone, especially the TXT records, because verification records for services you no longer use accumulate and nobody dares remove an unlabelled one.

Check the domain expiry date today, and again once a year.

Where you run this matters less than how, but if the provider is still open, the cloud account catalogue compares the options side by side.

For the vendor’s own reference on the services involved here, see the OVHcloud documentation.

If you would rather test this than read about it, our OVHcloud accounts come in four configurations across a wide product range, and the cloud account catalogue lists every provider we carry.

Questions people ask