DNS — the Domain Name System — is the piece of internet infrastructure that translates a domain name people can remember into the IP address a server actually listens on. It's easy to treat as a black box until a record change doesn't take effect the way you expected, at which point understanding what's actually happening becomes very useful, very quickly.

How DNS resolution actually works

When a browser needs to resolve example.com, it doesn't ask one server — it walks a hierarchy. First it checks its own cache and the operating system's resolver cache. If there's no cached answer, the request goes to a recursive resolver (often run by the ISP or a public service like a DNS provider), which queries a root server to find out which servers handle the .com top-level domain, then queries one of those TLD servers to find out which nameservers are authoritative for example.com specifically, and finally queries one of those authoritative nameservers for the actual record.

That entire chain typically completes in well under a second, and most of it is invisible to the end user — but every step is a place where a misconfiguration or a slow answer adds latency, and every step has its own caching behavior that affects how fast a change is seen.

The record types you'll actually use

A handful of record types cover almost everything a typical site or mail setup needs:

  • A record — points a hostname directly to an IPv4 address. This is the most common record for pointing a domain at a server.
  • AAAA record — the IPv6 equivalent of an A record.
  • CNAME record — points a hostname to another hostname rather than an IP, useful for subdomains that should follow whatever address a service uses (e.g. pointing www at a CDN endpoint).
  • MX record — tells the internet which mail servers accept email for the domain, and in what priority order.
  • TXT record — a free-form text field used for domain verification and, critically, for email authentication: SPF, DKIM and DMARC records all live here.
  • NS record — declares which nameservers are authoritative for the domain (or a subdomain, if delegated separately).

A domain rarely needs more than these. The mistake to avoid is treating DNS as a place to store arbitrary configuration — each record type has a specific job, and using the wrong one causes resolution failures that are disproportionately hard to diagnose.

Common mistakes per record type

Most day-to-day DNS problems trace back to one of a small number of record-specific mistakes:

  • A CNAME at the domain apex. The DNS spec doesn't allow a CNAME on a domain's bare root (example.com, as opposed to www.example.com) because a CNAME can't coexist with the other records — MX, NS — that the apex typically needs. Point the apex at an A or AAAA record instead, and use a CNAME only on subdomains.
  • An A record with no matching AAAA record, or vice versa. This isn't wrong by itself — plenty of sites are IPv4-only — but a stray AAAA record left pointing at an old, decommissioned IPv6 address after a migration will intermittently send IPv6-capable visitors to a dead endpoint, while everyone else resolves fine through the A record. If IPv6 isn't actively supported, don't leave a stale AAAA record behind.
  • Wrong MX priority values. Lower numbers are higher priority — a common reversal is setting a backup mail server's MX record to a lower number than the primary, which quietly routes mail through the backup path by default instead of using it as a fallback.
  • A trailing dot inconsistency in CNAME or MX targets. Some DNS panels require a fully-qualified target ending in a dot (mail.example.com.); omitting it in a manually edited zone file causes the record to be interpreted relative to the zone, silently pointing somewhere unintended.

Nameservers: who answers the question

A domain's nameservers determine who is authoritative for its DNS records — in other words, who gets to answer when the rest of the internet asks "where does this domain point?" Nameservers are usually set at the registrar level and typically come in pairs (sometimes more) for redundancy, so that if one is unreachable, resolution still succeeds through another.

Changing nameservers is a bigger, slower operation than changing an individual record, because it changes who the TLD servers point resolvers to in the first place — that referral is itself cached, so a nameserver change can take substantially longer to fully propagate than an ordinary record update at an existing DNS provider. Moving a domain between registrars is a related but separate operation — see Domain Transfer Explained for what does and doesn't change when that happens.

Verifying which nameservers are actually authoritative

It's easy to assume a domain is using the nameservers shown in the registrar's dashboard, but the only way to know for certain what the rest of the internet actually sees is to ask a resolver directly:

dig example.com NS +short

This returns the nameservers the domain's parent TLD is actually delegating to — if this doesn't match what the registrar dashboard shows, the delegation hasn't propagated yet, or was set incorrectly. A second, complementary check is to query one of those nameservers directly for a specific record, which confirms it's actually serving the expected answer rather than erroring or returning something stale:

dig example.com A @ns1.example-dns-provider.com

Querying a specific nameserver by name like this bypasses any resolver caching entirely, since it goes straight to the source — it's the most reliable way to confirm a record change has actually taken effect at the authoritative level, independent of how long it takes to reach every resolver on the internet.

TTL and why propagation takes time

Every DNS record has a TTL (Time To Live), which tells resolvers how long they're allowed to cache the answer before checking again. A 3600-second TTL means a resolver that already has the old answer cached won't ask again for up to an hour — which is exactly why DNS changes appear to "propagate" gradually rather than instantly: different resolvers around the world cached the previous answer at different times, and each keeps serving it until its own TTL expires.

The practical implication: if a migration or cutover is planned in advance, lower the TTL on the relevant records (to something like 300 seconds) a day or so before the change, wait for the old, longer TTL to fully expire out of caches, make the change, and only raise the TTL back to its normal value once the cutover is confirmed stable. Skipping this step is the single most common reason a "DNS change" seems to take an unpredictable amount of time to take effect everywhere. See DNS TTL Explained for a deeper look at exactly how TTL governs this.

Troubleshooting a real propagation delay

A typical version of this problem: an A record was updated to point a site at a new server, most visitors are landing on the new server correctly, but a handful of people — often including someone on the team, which is why it feels urgent — are still seeing the old site hours later. Working through it methodically usually finds the answer faster than guessing:

  1. Query the authoritative nameserver directly (as above, with dig example.com A @ns1...). If it already returns the new IP, the record change itself is correct and fully live — the problem is downstream caching, not the DNS configuration.
  2. Check the record's TTL before the change was made. A 24-hour TTL left in place means any resolver that cached the old answer within the last day can legitimately keep serving it for up to that long — this is expected behavior, not a fault.
  3. Ask the affected person to check from a different network — mobile data instead of home wifi, for instance. If the new site loads there, the issue is a stale cache on one specific device or router, not a DNS or propagation problem at all, and flushing that device's local DNS cache resolves it directly.
  4. If it's been well past the old TTL and step 1 still shows the old answer, the record change itself likely didn't save correctly at the DNS provider — recheck the zone editor rather than waiting longer.

This sequence isolates the fault to one of three places — the authoritative record, an in-flight TTL, or a local cache — rather than treating "it's still propagating" as an unfalsifiable explanation for every symptom.

Common operational mistakes

Beyond record-specific and propagation issues, a few operational patterns account for most other DNS-related outages and confusion:

  • Changing nameservers and a record at the same time. If the nameserver change hasn't finished propagating, the record change might be applied at the wrong provider entirely, or not visible where you're testing.
  • Forgetting MX records during a migration. Moving a domain's web hosting without carrying over its mail records silently breaks email delivery — a separate, easy-to-miss step.
  • High TTLs during a planned cutover. Leaving a 24-hour TTL in place going into a migration makes a slow, staggered rollout far more likely instead of a clean cutover window.

Checking and debugging DNS

Command-line tools remain the most reliable way to check what's actually being served, rather than relying on a browser that may itself be caching an old answer:

dig example.com A
dig example.com MX
dig example.com NS +short

dig queries authoritative servers directly and shows the TTL on the returned record, which is usually enough to explain why a change hasn't shown up everywhere yet. Checking from a second network (a phone on mobile data, for instance) is also a quick way to rule out a stale local cache as the culprit before assuming the DNS provider itself has a problem.