What you'll learn

  1. Quick answer
  2. How a name becomes an address
  3. The record types you will actually set
  4. TTL, and why propagation is the wrong word
  5. Why the same domain answers differently for two people
  6. Debugging DNS properly
  7. FAQ

Quick Answer

DNS turns a name into an address by asking a chain of servers: your resolver asks a root server, then the servers for the top-level domain, then the nameservers listed for your domain, which hold the authoritative answer. Every answer carries a TTL saying how long it may be cached. Changes look slow and inconsistent because different caches expire at different moments. Nothing propagates; stale answers simply time out.

How a name becomes an address

Your browser does not know what a domain means. Neither does your operating system. Resolution is a chain, and knowing the order is what lets you debug it.

First the stub resolver in your OS checks its own cache, and before that the hosts file. Then it forwards the query to a recursive resolver, usually run by your ISP such as Jio or Airtel, or a public one like 1.1.1.1 or 8.8.8.8 if you configured it. That resolver does the real work.

If it has nothing cached, it asks a root server, which does not know your domain but knows who runs .com. It then asks the TLD servers for .com, which do not know your address either but know which nameservers you delegated your domain to. Finally it asks one of those authoritative nameservers, which holds the actual record and answers.

The distinction worth stating in an interview: your machine makes a recursive query, meaning give me the final answer. The resolver then makes iterative queries, meaning tell me who to ask next. That is why one lookup involves several servers but your application sees only one request.

Every step caches. The root and TLD answers get cached for a long time, so in practice the first two hops are skipped almost always. This is also why the very first visit to a new domain feels slower than every later one.

browser cache
  -> OS stub resolver + hosts file
    -> recursive resolver (ISP or 1.1.1.1)
      -> root servers        who runs .com?
      -> .com TLD servers    which nameservers for this domain?
      -> authoritative NS    here is the A record

The record types you will actually set

A domain's zone is a set of records. You will use six of them in real life.

  • A maps a name to an IPv4 address. AAAA does the same for IPv6.
  • CNAME is an alias pointing one name at another name. Used constantly for CDN and hosting endpoints.
  • MX tells other mail servers where to deliver your email, with a priority number where lower means preferred.
  • TXT holds arbitrary text. In practice it holds SPF, DKIM and DMARC policies for email, plus domain ownership verification strings.
  • NS names the authoritative nameservers for the zone. This is what you change at the registrar when you move hosting.
example.com.        3600  IN  A      203.0.113.10
www.example.com.    3600  IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mail.example.com.
mail.example.com.   3600  IN  A      203.0.113.20
example.com.        3600  IN  TXT    "v=spf1 include:_spf.example.net -all"
example.com.        86400 IN  NS     ns1.hostingprovider.com.

Now the rule that catches almost everyone. A CNAME cannot coexist with any other record on the same name. That is not a provider limitation, it is how DNS is defined. Since your apex domain must have NS and SOA records, it can never have a CNAME. This is why www.example.com can be a CNAME to your host but example.com cannot, and why hosting providers invented non-standard ALIAS or ANAME records that look like a CNAME in the panel but return an A record in the answer.

Two related traps. An MX record must point to a hostname, never to an IP address, and that hostname must resolve to an A record and must not itself be a CNAME. And your SPF TXT record must be a single record: publishing two separate SPF strings makes the check fail rather than merge, which quietly sends your transactional email to spam.

TTL, and why propagation is the wrong word

Every DNS answer carries a TTL in seconds. It is an instruction to the caching resolver: you may reuse this answer for this long, then ask again.

That is the entire mechanism. When you change an A record, nobody is notified. No update is pushed anywhere. The authoritative server simply starts giving a new answer, and every cache in the world keeps serving the old one until its own countdown reaches zero. Nothing propagates. Things expire.

The consequence is the single most useful DNS habit there is: lower the TTL before the migration, not during it. If your record has a TTL of 86400 and you change it today, resolvers that cached it an hour ago will keep the old address for nearly a full day. If instead you set the TTL to 300 a day in advance, then by the time you actually switch, every cache holds a five-minute copy and the cutover is quick. Raise the TTL again once you are stable, because very low TTLs mean more lookups and slightly slower page loads.

Day 1:  set TTL to 300 on the records you will change
Day 2:  wait out the OLD TTL so caches now hold 5-minute copies
Day 2:  change the record, switch traffic, watch for problems
Day 3:  raise TTL back to 3600 or higher

Nameserver changes are a different beast. When you point your domain at new nameservers at the registrar, the record that must expire lives at the TLD level, and those delegation records commonly carry a TTL of a day or two. That is why record edits can take minutes while a nameserver switch can take much longer. Plan a hosting move around the nameserver TTL, not the record TTL, and keep the old host serving the site until the switch has fully settled.

Why the same domain answers differently for two people

You change a record, your phone on mobile data shows the new site, your laptop on Wi-Fi shows the old one, and a friend sees a mix. This is not a bug and it is not a partial update.

There are at least five independent caches involved, each with its own clock:

  • Browser cache. Chrome and Firefox keep their own short DNS cache, separate from the OS.
  • OS cache. Windows caches aggressively. Clear it with ipconfig /flushdns. On Linux with systemd-resolved use resolvectl flush-caches. On macOS use sudo dscacheutil -flushcache followed by killing mDNSResponder.
  • Your router. Many home routers act as a forwarding resolver with their own cache, which is why a router reboot sometimes fixes it.
  • The ISP resolver. Each one started caching at a different moment, so each expires at a different moment. A few ignore short TTLs and enforce a floor of their own.
  • Negative caching. If you queried the name before the record existed, the NXDOMAIN answer is itself cached, governed by the zone's SOA minimum. This is why a brand new subdomain sometimes stays broken for you specifically while working for everyone else.

There is one more reason answers legitimately differ and it is not staleness at all. CDNs and geo-aware DNS return different addresses depending on where the resolver is. Someone in Pune and someone in Singapore querying the same hostname should get different IPs. If you are comparing answers across cities to check a deployment, you are comparing two correct answers.

Also worth knowing: many browsers now use DNS over HTTPS, so the browser may resolve through a provider your operating system never sees. Flushing the OS cache then changes nothing, and the fix is to clear the browser's own resolver cache instead.

Debugging DNS properly

Stop using ping to check DNS. Ping goes through your OS resolver and its cache, mixes in ICMP behaviour, and tells you nothing about which record answered. Query the DNS layer directly.

# Linux, macOS, or Git Bash on Windows if dig is installed
dig example.com A +short
dig example.com MX
dig example.com TXT

# ask a specific resolver, bypassing your ISP
dig @1.1.1.1 example.com A

# ask the authoritative server, bypassing every cache
dig @ns1.hostingprovider.com example.com A

# walk the chain from the root, which shows the delegation
dig example.com +trace

The most valuable line there is querying the authoritative nameserver directly. If the authoritative server returns the new value and a public resolver returns the old one, the change is correct and you are simply waiting out a TTL. If the authoritative server itself returns the old value, you edited the wrong zone, which usually means the domain is delegated to different nameservers than the control panel you are editing.

dig is not installed on Windows by default. Use the built-in tools instead, and note that PowerShell's version is the more readable one.

nslookup example.com
nslookup -type=MX example.com 8.8.8.8

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1

Read the TTL in the answer, not just the value. A response with a TTL of 240 when you configured 3600 means a resolver cached it 3360 seconds ago and will refresh in four minutes. That number tells you exactly how long to wait instead of guessing.

Finally, remember the hosts file. If a site resolves correctly for everyone except you, check C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux and macOS. A line left behind from local testing overrides DNS entirely and no amount of cache flushing will help.

Frequently Asked Questions

How long does a DNS change really take? As long as the TTL that was in effect before you made the change. If the old record had a TTL of 3600, a resolver that cached it fifty minutes ago will refresh in ten minutes, and one that cached it a minute ago will wait almost an hour. The maximum wait is the full old TTL, which is why lowering it in advance is the only reliable way to make a switch fast.
Why can I not put a CNAME on my root domain? Because a CNAME cannot coexist with any other record on the same name, and the root of a zone must carry NS and SOA records. Providers work around this with ALIAS, ANAME or CNAME flattening, which resolve the target internally and hand back a normal A record. Those are provider features, not standard DNS record types.
What is the difference between a recursive and an authoritative nameserver? A recursive resolver answers on your behalf by asking other servers and caching what it learns. An authoritative nameserver holds the actual zone data for a domain and answers only for the domains it is responsible for. When you edit records in a hosting panel you are editing the authoritative side, and everything else is a cache of it.
Is a lower TTL always better? No. Low TTLs mean caches expire constantly, so more lookups happen and each first request on a page can pay extra latency. Use a short TTL of a few minutes around a planned migration, then raise it back to something like an hour once things are stable. Permanently short TTLs also make you more exposed if your DNS provider has an outage.
Why do email records keep breaking after a hosting migration? Because moving nameservers moves the entire zone, and the new provider rarely recreates your MX, SPF, DKIM and DMARC records automatically. Export every record from the old zone before switching and recreate them at the new provider first. Email failures are also slower to notice than website failures, so they often surface days later.