Guide

DNS troubleshooting

Most DNS problems are one of four things. Here is how to find out which.

Start by deciding whether it is DNS at all

DNS gets blamed for a great many outages it had nothing to do with, because it is the first thing in the chain and the easiest thing to suspect. The first question is therefore not "what is wrong with my DNS" but "does DNS return the right answer".

If every resolver you check returns the record you expect, DNS has done its job and the problem is downstream: the host may be unreachable, the service may not be listening, or the certificate may not cover the name. Those are three different investigations, and none of them is helped by editing a zone file.

If resolvers disagree with each other, or return something you did not configure, then it is DNS — and it is almost always one of the four situations below.

Symptoms and what they actually mean

Symptom	What it means	What to check
NXDOMAIN	The name does not exist in the zone	Spelling, and whether the record is in the zone you think it is
Resolvers disagree	A change is still working through caches	The TTL on the old record — that is your remaining wait
Right record, site still down	Not a DNS problem	Reachability on the port, and the certificate name
Works without www, fails with it	A missing record, not a propagation delay	Whether www has its own A or CNAME record
Mail failing, web fine	MX or SPF, not the A record	MX records, and the TXT record holding SPF

Propagation is a misleading word

Nothing propagates. When you change a record, no message is sent to the world's resolvers and no queue drains. What happens is simpler and less forgiving: every resolver that already asked is holding the previous answer, and it will keep holding it until the TTL it was given expires. Then it asks again and gets the new value.

This has one important consequence. The wait is not measured from when you made the change — it is measured from when each resolver last cached, using the old TTL. Lowering the TTL at the moment of the change does nothing for anyone already holding an answer, because they were handed the old, longer lifetime.

The practical rule: lower the TTL at least one full old-TTL period before a planned change, make the change, then raise it again afterwards. Do that and a migration is a five minute window instead of a day of inconsistent behaviour.

Which caches you can clear, and which you cannot

Layer	How long it holds	How to clear it
Browser	Seconds to a minute	Restart, or the browser’s own DNS cache page
Operating system	Minutes	ipconfig /flushdns, or resolvectl flush-caches
Router	Varies, often long	Reboot it
Recursive resolver	The record’s TTL	Nothing — you wait
Authoritative server	None — this is the source	Not a cache

The one that matters is the recursive resolver, and it is the one you cannot touch. Flushing your own caches makes your machine see the change; it does nothing for the visitor reporting the problem, whose resolver is holding its own copy for its own remaining TTL.

Records versus delegation

These produce similar symptoms and have completely different fixes, so it is worth separating them early.

A records problem is a wrong or missing value inside a zone you control. The nameservers are correct, they are answering, and the answer is not what you wanted. This is the common case and the easy one.

A delegation problem is that the parent zone — held by the registry, populated from your registrar — points at nameservers that are not the ones actually serving your zone. Resolvers dutifully ask the servers they are told to ask, and get a stale answer or none at all. You can edit records all day in the zone you are looking at and change nothing, because nobody is asking that server.

The check is direct: compare the NS records the registrar publishes against the NS records the zone itself returns. If they differ, that is the problem, and no amount of waiting will fix it.

The two-resolver comparison

Most of this can be settled by asking more than one resolver the same question. If Cloudflare, Google and Quad9 all return the same value, that value is what the internet currently believes. If they differ, you are watching a change work through caches and the TTL tells you how much longer.

Worth knowing about the comparison: public resolvers are anycast, so you are querying whichever node is nearest whoever is doing the asking. Two people running the same comparison from different continents are talking to different machines, and a disagreement between them is normal during a change rather than evidence of a fault.

The order that saves the most time

Check the authoritative answer first — it tells you whether the zone contains what you think. Then compare public resolvers, which tells you whether a change is still working through. Then check delegation, which explains any answer that seems to come from nowhere. Only then look at local caches, which are the layer people usually start with and the layer that least often explains someone else's problem.

Frequently asked questions

How long does DNS propagation actually take?

There is no propagation in the sense the word implies. Nothing is pushed anywhere — resolvers simply cache an answer for as long as its TTL says, then ask again. So the honest figure is "up to the old TTL", counted from when each resolver last cached. If the record had a 3600-second TTL, some resolvers will hold the old answer for an hour after you change it, and no amount of waiting for propagation makes that faster.

I changed a record and I still see the old value. Where is it cached?

Four places, and it is worth knowing which. Your browser keeps its own short cache; your operating system keeps one; your router often keeps one; and your ISP or public resolver keeps the one that actually matters. Querying an authoritative nameserver directly skips all four and tells you what the zone really contains — if that answer is correct, your change worked and you are looking at a cache.

The site works for me but not for someone else. Where do I start?

Compare what different resolvers return for the same name. If they disagree, it is a caching or propagation question and it resolves itself as TTLs expire. If every resolver agrees and returns the correct record, DNS is not your problem — check whether the destination is reachable on the port in question, and whether the certificate matches the name being used.

What TTL should I use?

Low enough that a mistake is cheap to undo, high enough that you are not paying for lookups you do not need. 3600 seconds is a reasonable default for records that rarely change. Before a planned migration, lower it to 300 at least one full old-TTL period in advance — dropping it an hour before a cutover does nothing, because resolvers are still holding the answer that carried the old value.

Why does dig give a different answer to my browser?

Because they usually ask different resolvers. Command-line tools generally use the system resolver, while modern browsers increasingly use DNS-over-HTTPS with a provider of their own — often Cloudflare or Google — regardless of what the operating system is configured to use. That is a common and confusing source of disagreement, and it is a browser setting rather than a DNS fault.

What is a delegation problem, and how is it different?

A records problem means the zone contains the wrong value. A delegation problem means the parent zone points at the wrong nameservers, so resolvers are asking a server that is not authoritative — or is authoritative for a stale copy. The tell is that the NS records at the registrar do not match the NS records the zone itself publishes. Fixing records in the wrong zone is the classic wasted afternoon.

Try it yourself

Everything above is easier to follow against a real answer.