DNS in Depth: Resolvers, Records, TTL, and Production Debugging

Part 1 of this series treated DNS as a quick lookup: domain name goes in, IP address comes out. That explanation is useful until a migration works from one network but not another, a resolver keeps returning an old address, or DNSSEC makes a domain disappear for validating clients.

This is Part 3 of the How the Web Works series. It covers the naming layer used before a client can open a new connection to a hostname. Cached answers and reused connections mean a fresh DNS lookup does not occur for every HTTP request.

---

Quick Answer

DNS converts a domain name into an IP address through a chain of caches and servers, roughly:

Browser cache
      ↓ (miss)
OS resolver cache
      ↓ (miss)
Router / ISP resolver cache
      ↓ (miss)
Recursive resolver queries the internet:
      Root server → TLD server → Authoritative server
      ↓
Answer flows back and may be cached by the resolver, OS, and browser

Many lookups are answered from a local or recursive-resolver cache, which is why DNS usually feels instant. The full delegation chain is followed only when the recursive resolver lacks a usable cached answer; latency then depends on network distance, retries, and how much delegation information is already cached.

---

Why DNS Exists

Network packets are routed using IP addresses, while applications benefit from stable names. DNS provides human-readable naming, delegation, indirection, and service-discovery records so addresses and providers can change without every client hardcoding them. It is distributed, hierarchical, and heavily cached so no single server answers for the entire internet and repeated lookups are efficient.

suriyaprakash.in  →  DNS resolution  →  188.114.97.3

That simple mapping involves caching decisions, authority delegation, and optionally cryptographic verification that the answer was not tampered with in transit.

---

The DNS Resolution Path Step by Step

1. Local caches are checked first

Before opening a new connection, a browser may check its own host cache and may ask the operating system resolver. Some browsers instead use a configured encrypted resolver such as DoH. Many "DNS problems" are stale-cache problems: the authoritative data has changed, but a previously cached answer is still valid for its remaining TTL.

2. The recursive resolver takes over

If nothing local has an answer, the query goes to a recursive resolver, usually your ISP's resolver or a public one like 1.1.1.1 or 8.8.8.8 if configured. This resolver does the multi-hop work on your behalf and caches the result for other users behind the same resolver.

3. Root → TLD → Authoritative

Recursive resolver asks: where is suriyaprakash.in?

Root server:        "I don't know, but ask the .in TLD server"
       ↓
.in TLD server:      "I don't know the IP, but ask this authoritative server"
       ↓
Authoritative server: "Here's the A record: 188.114.97.3"

The authoritative server is configured for the domain, often through a DNS provider, and is the source of truth for that zone. For a typical second-level lookup, root and TLD servers return referrals toward the appropriate authoritative servers rather than the final address record.

4. The answer can be cached on the way back

The recursive resolver normally caches the answer according to its TTL, subject to local policy and TTL caps. The operating system and browser may also cache it. These caches are why a later lookup for the same name can be close to instant.

---

DNS Record Types You'll Actually Use

A frequent gotcha: in standard DNS, a CNAME cannot coexist with other records on the same owner name, such as MX or TXT. A CNAME means "this name is an alias for that other name." This is why root domains (example.com, not www.example.com) usually need A/AAAA records, ALIAS/ANAME-style provider behavior, or CDN-specific flattening instead of a normal CNAME.

---

TTL and Propagation

TTL (Time To Live) is how long, in seconds, a resolver is allowed to cache a record before asking again.

example.com.  IN  A  300  188.114.97.3
                      ↑
                 TTL in seconds (5 minutes)

"DNS propagation" is mostly the period during which recursive resolvers still hold older cached answers, although provider publication delays, delegation changes, and negative caching can also matter. A resolver that cached a record shortly before you changed it can continue serving the old answer until that cached TTL expires, subject to the resolver's own caching policy.

Practical implication: lower the TTL before a planned migration (a day or more in advance, since the old, longer TTL is still in effect until it expires), let the low TTL propagate, make the change, then raise the TTL back once things are stable.

---

Recursive Resolvers, Root, TLD, and Authoritative Servers

It's worth being precise about who does what, because debugging depends on knowing which layer to blame:

• Recursive resolver: does the lookup work and caches results. This is what "my DNS" usually refers to.
• Root servers: 13 logical root server addresses, each backed by many physical machines via anycast, that know which TLD servers to ask next.
• TLD servers: handle one top-level domain each (.com, .in, .dev, etc.) and know which authoritative servers to ask next.
• Authoritative servers: hold the records for a specific domain, configured by whoever manages that domain's DNS.

A bad authoritative record can eventually affect all clients that refresh that answer, although existing caches may delay the impact. A problem at one recursive resolver primarily affects clients using that resolver. That is why "it works on mobile data but not office Wi-Fi" often points to resolver-specific caching, filtering, or split-horizon configuration.

---

Caching Layers and Why "It's Already Fixed" Doesn't Always Feel True

This is the single most common source of DNS confusion: the authoritative record is correct, but a cache somewhere between you and it hasn't caught up.

Browser host cache       ← implementation-specific; may clamp TTLs
      ↓
OS/stub resolver cache   ← implementation-specific
      ↓
Local network cache      ← present only on some routers/networks
      ↓
Recursive resolver       ← caches answers, usually shared by many clients

When someone says "I updated the DNS record but it's still showing the old site," compare the authoritative answer with several recursive resolvers first. The cause may be an unexpired cache, but it can also be a provider publication issue, incorrect delegation, negative caching, or an application/CDN cache that is unrelated to DNS.

---

DNSSEC: Verifying DNS Responses Aren't Forged

Plain DNS has no built-in way to verify that a response came from the real authoritative server and was not forged in transit. DNSSEC adds a chain of cryptographic signatures on top of DNS records, so a validating resolver can verify a response before trusting it.

Root trust anchor validates the root DNSKEY
      ↓
Parent zone publishes a DS record for the child zone
      ↓
The DS authenticates the child DNSKEY
      ↓
The child zone signs its DNS record sets (RRsets)

Each parent-to-child DS/DNSKEY relationship extends the chain of trust from the root to the signed record set. If a validating resolver receives a response that fails signature verification, it refuses to return the answer. A DNSSEC misconfiguration, such as an expired signature, can therefore break a domain for DNSSEC-validating resolvers even when the plain records look correct.

---

Split-Horizon and Internal DNS

Split-horizon DNS means the same domain name resolves to different answers depending on who is asking. A common setup is an internal company network resolving api.company.com to a private internal IP, while the public internet resolves the same name to a public load balancer.

This is normal in corporate and VPN setups, but it causes many "works on my machine" bugs. Two people can get different, valid answers to the same DNS query depending on which network and resolver they use.

---

DNS Over HTTPS and DNS Over TLS

Plain DNS queries are sent unencrypted, usually over UDP port 53. Anyone on the network path can see which domains you are looking up, and without DNSSEC they may be able to tamper with the response.

• DoH (DNS over HTTPS): DNS queries wrapped inside a normal HTTPS request, often to a resolver like 1.1.1.1 or 8.8.8.8. It is increasingly built directly into browsers and can bypass OS-level DNS settings.
• DoT (DNS over TLS): a similar encryption goal, but over a dedicated TLS connection instead of piggybacking on HTTPS.

The practical implication for debugging: if a browser has DoH enabled, nslookup/dig run from a terminal (which use the OS resolver) may show a different answer than what the browser is using, because the browser skipped the OS resolver entirely.

---

Common DNS Failure Modes

---

Practical Debugging Checklist

1. Check what is being returned right now

dig suriyaprakash.in
dig +short suriyaprakash.in
dig @1.1.1.1 suriyaprakash.in
dig NS suriyaprakash.in +short

Querying @1.1.1.1 shows Cloudflare's recursive-resolver view, which may itself be cached. To inspect the source directly, obtain an authoritative nameserver from the NS answer and query it explicitly, for example dig @<authoritative-ns> suriyaprakash.in A.

2. Trace the full resolution path

dig +trace suriyaprakash.in

+trace follows referrals from the root toward the authoritative zone. It is useful for finding delegation problems, but it is not identical to what a particular recursive resolver or browser sees.

3. Check TTL and record type

dig suriyaprakash.in A
dig suriyaprakash.in AAAA
dig suriyaprakash.in CNAME
dig suriyaprakash.in NS
dig suriyaprakash.in SOA

Query the record types you need explicitly. ANY queries are frequently minimized, refused, or answered with only a subset of data, so they are not a reliable way to dump an entire zone.

4. Rule out local caching

Chromium-based browsers: browser network/DNS settings → clear host cache (UI varies by version)
macOS:   sudo killall -HUP mDNSResponder
Linux with systemd-resolved: sudo resolvectl flush-caches
Windows: ipconfig /flushdns

5. Check DNSSEC validation

dig @1.1.1.1 +dnssec suriyaprakash.in
delv suriyaprakash.in   # where BIND's validating resolver tool is available

The +dnssec option requests DNSSEC records; it does not perform validation by itself. An ad flag means the recursive resolver claims it validated the answer. Trust that signal only when the resolver and the path to it are trusted; use a validating tool such as delv for an independent check.

---

Three Operational Lessons

The short explanation:

DNS translates domain names to IP addresses using a hierarchy of servers.

The details worth carrying into an incident are:

• The caching hierarchy and why "propagation" is really just cache expiry, not distribution delay
• Why TTL needs lowering ahead of a migration, not during it
• The difference between recursive resolvers and authoritative servers when isolating a failure
• DNSSEC's chain of trust and how an expired signature can take a domain offline for validating resolvers
• Why split-horizon DNS makes "works for me" genuinely meaningless without knowing which network the person is on

---

FAQ

Why does a DNS change take time to show up everywhere?

Because resolvers that cached the old record can continue serving it until their cached lifetime ends. There is usually no global push of the new value; resolvers refresh independently, and local TTL caps, early eviction, stale-answer serving, negative caching, and provider/delegation changes can alter the exact timing.

Does lowering the TTL make a change happen faster?

Only if you lower it before making the change. If a resolver already cached the record under the old, longer TTL, lowering the TTL afterward doesn't retroactively shorten a cache that resolver already has.

What's the difference between a recursive resolver and an authoritative server?

A recursive resolver does the work of tracking down an answer on your behalf and caches the result. An authoritative server is the actual source of truth for a specific domain's records, configured by whoever manages that domain.

Why would DNSSEC take a site offline even if the DNS records look correct?

If DNSSEC signatures are expired or misconfigured, resolvers that validate DNSSEC will refuse to trust the response and will not return it, even when the underlying A/AAAA records are correct.

Can two people get different, both-correct answers for the same domain?

Yes. With split-horizon DNS, internal and external networks can intentionally resolve the same name to different IPs, so both answers can be correct depending on which network asked.

Is DNS over HTTPS the same as DNSSEC?

No. DoH/DoT encrypt the DNS query and response in transit so it is harder to read or tamper with on the wire. DNSSEC cryptographically verifies that a response came from the legitimate authoritative chain. They solve different problems and can be used independently or together.

Why does dig show a different answer than my browser is using?

If the browser has DNS over HTTPS enabled, it may be using its own built-in resolver entirely, bypassing the OS resolver that command-line tools like dig/nslookup query by default.

---

Glossary

---

Final Mental Model

Domain name typed
      ↓
Local caches checked (browser, OS, router)
      ↓
Recursive resolver takes over on a miss
      ↓
Root → TLD → Authoritative server chain
      ↓
Answer returned and cached where the implementation permits
      ↓
(Optionally) DNSSEC verifies the answer wasn't forged
      ↓
IP address handed back to the browser

With this model, "the DNS is broken" becomes a specific question: which layer in this chain is holding the wrong answer, and how much TTL remains?

---