Why DNS Mistakes Break Sites That Look Fine to You

In short

DNS mistakes break a website for some visitors while it keeps working for
you, because your browser caches old answers you no longer see. The usual
culprits are a missing www-or-apex record, a single nameserver, a dangling
CNAME pointing at a service you no longer own, and a TTL set so high a fix
takes days to reach everyone. SiteHealth checks these DNS records from
outside your network on a schedule, so the gap shows up as an alert instead
of a lost customer.

What is DNS, in plain terms?

DNS, the Domain Name System, is the directory that turns a name like
yoursite.com into the numeric address a browser needs to find your server.
Every domain has a set of records, each controlling one specific piece:

• A / AAAA record — points a domain or subdomain straight at a server's
• numeric address; this is what makes the site itself load.
• CNAME record — points a subdomain at another name instead of a raw
• address, commonly used for www or a third-party service.
• MX record — tells the internet which mail servers accept email for
• the domain.
• NS record — names which nameservers are allowed to answer DNS
• questions for the domain at all.
• TTL — the number of seconds any of the above may be cached before a
• server has to ask again.

A mistake in any one of these records affects only the piece it controls,
which is exactly why DNS problems are so easy to miss: the rest of the
domain keeps working and nobody notices the one broken piece until a
visitor hits it.

Why does my site work for me but not for a customer?

Your browser and phone cache DNS answers for as long as the record's TTL
says to, so you keep seeing the old, working answer long after you changed
something. A customer on a different network, a different device, or simply
a machine that has not visited your site recently asks the DNS servers
fresh and gets whatever is actually configured right now. This is why "it
works when I check it" is not proof anything is fixed. The two of you are
reading from different caches of the same record.

Why does my site load with www but not without it, or the other way around?

This is the address-variants problem: yoursite.com, www.yoursite.com,
http://, and https:// are four different addresses to a browser, and
each one needs its own working record and a redirect to the version you
actually want people to land on. A site that only configured the www
subdomain will fail for anyone who types the bare domain, and vice versa.
Social media profiles, old backlinks, and business cards often use whichever
version someone typed once, so both need to resolve and both need to
redirect to one canonical address.

What is a dangling CNAME, and why does it matter?

A CNAME record points a subdomain, like app.yoursite.com, at another
service's address instead of a raw IP. A dangling CNAME is one left behind
after you stop using that service, canceled an account, deleted a hosting
app, moved off a platform, while the DNS record still points at it. Anyone
who can register that same service name elsewhere can then claim your
subdomain and serve their own content from it, under your domain, which is
a real subdomain-takeover risk, not a theoretical one. The fix is simple
once you know to look: delete the CNAME the same day you stop using the
service it points to, not "eventually."

How do I check my own DNS for these mistakes?

1. List every DNS record your domain currently has, using your registrar's
2. or DNS host's control panel, not memory of what you set up once.
3. For each CNAME, confirm the service it points to is still active and
4. still yours; delete any that point to something canceled or deleted.
5. Confirm both the apex domain and the www subdomain have working records,
6. and that one redirects to the other.
7. Confirm the domain has at least two nameservers listed, from your
8. registrar's standard pair, not one.
9. Check the MX records against what your mail provider currently tells you
10. to use, since a past migration can leave an old provider's MX records
11. active alongside the new ones.
12. Query each record from a tool outside your own network and compare the
13. answer to what your control panel shows, rather than trusting a browser
14. reload.

Doing this by hand once catches what is broken today. Catching a record
that silently drifts three months from now, after a migration or a canceled
service you forgot about, is a different job, and it is the reason DNS
checks belong on a recurring schedule rather than a one-time audit.
SiteHealth's checks run that DNS review automatically, on the
same hourly schedule as its SSL, email, and payment-page checks, and it
sends a plain-English alert the moment a record stops matching what it
expects.

What does a low or high TTL actually control?

TTL, time-to-live, is a number in seconds attached to each individual DNS
record, telling other servers how long they may cache that answer before
asking again. A record with a 300-second TTL is nearly fully updated within
five minutes of a change; a record left at the common default of 86,400
seconds, 24 hours, will keep serving the old answer to some fraction of
visitors for a full day. "DNS takes 24 to 48 hours to propagate" is a myth
stated as if it were a universal internet rule; in reality it is just
whatever TTL you left on the record, and lowering it to 300 seconds a day
before a planned change is the standard way to make the actual cutover fast.

Why does having only one nameserver matter?

Nameservers are the machines that actually answer DNS questions for your
domain, and the NS records at your registrar list which ones are allowed to
answer. Most registrars hand you two by default, but it is possible to end
up with only one live, usually after a migration where the old provider's
second nameserver was removed and never replaced. With one nameserver, an
outage at that single provider means your domain stops resolving anywhere
on the internet, not just slows down, so the site, the mail, and any
checkout page tied to the domain all go dark at the same moment, for as
long as that one provider is down. Two independent nameservers mean one can
fail while the other keeps answering, which is the entire reason the
standard has always been a pair, not a single record.

What if my agency or freelancer built the site, not me?

If someone else set up your DNS, "I don't know who has the login" is the
single most common reason a dangling CNAME or a single nameserver survives
for years, because nobody who currently touches the site has ever looked at
the DNS records at all. That is a real gap, not a reason to skip the
check: your registrar account, whoever holds it, always has read access to
the current records even if nobody remembers configuring them. Agencies
running DNS across multiple client domains run into this
constantly, because ownership of the DNS panel tends to sit with whoever
registered the domain years ago, not whoever currently maintains the site.

What should I check right now?

Start with the free checker at SiteHealth and run it against your own
domain; it needs no account and will flag an address-variant mismatch,
missing records, or an unreachable nameserver in under a minute. If you want
DNS checked on a schedule instead of once, alongside the SSL, email, and
exposed-file checks covered in what to check before pointing a domain at an
AI-built site and why an
SSL certificate expires without warning,
sign up and add the domain; the first hourly check runs
automatically.