DNS is the layer everyone depends on and almost nobody looks at directly. It is also where a startling number of outages live — the site is fine, the server is fine, and a record that changed at 3am is quietly sending everyone somewhere else.

Query any public domain with the DNS Lookup tool.

The records you will actually meet

A — maps a hostname to an IPv4 address. The most fundamental record there is.

AAAA — the same for IPv6. Worth checking: a domain with an AAAA record pointing at a server that is not actually listening on IPv6 fails for IPv6-capable clients while working perfectly for everyone else. That produces the maddening "it works for me" bug report.

CNAME — an alias. www.example.com is a CNAME to example.com, so both resolve to the same place and you only maintain one A record. The rule that catches people: a CNAME cannot coexist with other records on the same name, which is why you cannot CNAME the bare domain when it also needs MX records. Providers work around this with ALIAS or ANAME records that behave like a CNAME but resolve server-side.

MX — where email for the domain should go, each with a priority number. Lower numbers are tried first. A domain with no MX records cannot receive mail.

TXT — arbitrary text, and in practice the workhorse. SPF, DKIM, DMARC and every domain-verification string live in TXT records.

NS — which nameservers are authoritative for the zone. If these are wrong, nothing else matters.

CAA — which certificate authorities may issue certificates for the domain. Underused, and genuinely useful: it stops a CA you have never dealt with issuing a certificate for your name.

TTL: the number that decides how long mistakes last

Every record carries a time-to-live in seconds, telling resolvers how long they may cache it.

A TTL of 86400 is 24 hours. Change that record and some resolvers will keep serving the old value for a full day. You cannot force them to forget.

This is why the standard migration procedure is: lower the TTL first, to 300 seconds, at least a day before you plan to change anything. Then make the change, watch it propagate in five minutes rather than a day, and raise the TTL back afterwards.

Skipping that step is the single most common cause of a migration that takes a day to settle instead of ten minutes. And "DNS propagation" is a slightly misleading phrase — nothing is being pushed anywhere. Caches are simply expiring at different times, which is why the change appears for some people long before others.

Why two people get different answers

There is no single global DNS. There is a hierarchy, and thousands of independent resolvers each holding their own cache.

So your ISP's resolver may hold a record for another six hours while Cloudflare's 1.1.1.1 already has the new one. Both are behaving correctly. When someone reports that a site works for them and not for you, resolver caching is the first thing to check — before anyone starts restarting servers.

Checking from a browser-based tool queries from a different vantage point than your own machine, which is exactly what makes it useful for this.

What DNS reveals

DNS is public by design, and it says more about an organisation than people expect.

MX records show which mail provider is in use. TXT records list every SaaS product that required domain verification. NS records reveal the DNS provider, and often the hosting provider by extension. A CNAME to a vendor's domain names the vendor outright.

None of that is a vulnerability. It is reconnaissance, and it is the first thing anyone assessing a domain looks at — including attackers, which is a reason to know what your own records are advertising.

The genuine risk is the dangling record: a CNAME pointing at a cloud resource that no longer exists. If somebody else can claim that resource name, they inherit a subdomain of yours — subdomain takeover. Old records for decommissioned services are worth auditing periodically.

A practical check

  1. Query A and AAAA. Confirm any AAAA record points somewhere that genuinely answers.
  2. Query MX if the domain receives mail, and check the priorities make sense.
  3. Query TXT and read what is there — old verification strings from services you stopped using are clutter and mild information leakage.
  4. Query NS and confirm they match the provider you expect.
  5. Check CAA. If absent, consider adding one.
  6. Look for CNAMEs pointing at services you no longer run.

From a terminal, dig A example.com +short and dig TXT example.com +short cover most of it. dig +trace walks the delegation from the root when something is genuinely broken.

Common questions

How long do DNS changes take?
Up to the old record's TTL. Lower the TTL a day in advance and changes appear in minutes.

Why can I CNAME www but not the bare domain?
A CNAME cannot coexist with other records on the same name, and the bare domain needs MX and NS records. Use ALIAS or ANAME if your provider offers it.

Why does the site work for someone else but not me?
Different resolvers hold different cached copies. Yours has not expired yet.

What is a dangling DNS record?
A CNAME pointing at a service that no longer exists. If someone else claims that name, they control your subdomain.

Where to go next