DNS Resolution, TTL Caching, and Frontend Delivery

Medium•

Comic-style DNS resolution flow showing browser cache, recursive resolver, root, top-level domain, authoritative server, Time To Live caching, and cached answer.

DNS is a control plane that influences the data plane. A DNS record change is made at the authoritative DNS provider, but users experience cached answers from recursive resolvers and local caches until those entries expire. Strong frontend engineers understand the resolution path, the cache layers, the record types used for CDNs and APIs, and the operational failure modes that make DNS incidents feel inconsistent across regions and networks.

Quick Navigation: Resolution Path Mental Model • Record Types Frontend Engineers Should Know • TTL Strategy: Agility vs Cache Efficiency • Cache Layers and What They Hide • Negative Caching and NXDOMAIN • CDN and Multi-Region Routing • Frontend Performance Implications • Failure Modes and Recovery Policy

Resolution Path Mental Model

A cold lookup usually follows a hierarchy like this:

Browser
  -> operating system cache
  -> recursive resolver
  -> root nameserver
  -> TLD nameserver
  -> authoritative nameserver
  -> answer cached and returned

TLD means Top-Level Domain, such as .com or .dev. The authoritative nameserver is the source of truth for the zone, but most user requests do not reach it once records are cached.

Frontend example

When a user opens a page that fetches:

https://www.example.com
https://api.example.com
https://assets.examplecdn.com
https://fonts.example.net

each distinct hostname may need DNS resolution unless already cached. That lookup happens before the browser can open the relevant connection. This is why too many critical third-party origins can hurt cold-load performance.

Record Types Frontend Engineers Should Know

Record	Meaning	Frontend relevance
A	hostname to IPv4 address	direct origin or load balancer address
AAAA	hostname to IPv6 address	IPv6-capable origins and CDNs
CNAME	alias one hostname to another	custom domains pointing to CDN or hosting provider targets
TXT	arbitrary text metadata	domain verification and security-related policies
CAA	which Certificate Authorities may issue certificates	certificate governance for HTTPS

TTL Strategy: Agility vs Cache Efficiency

TTL choice	Better for	Hidden cost
Short TTL, such as 30-300 seconds	migrations, failover, rollback, experiments	more resolver queries and less cache efficiency
Long TTL, such as 1-24 hours	stable records and lower query volume	slower visible recovery when the answer must change

Cache Layers and What They Hide

DNS caching can happen at several layers:

•browser DNS cache

•operating system DNS cache

•local network resolver

•ISP or public recursive resolver

•enterprise DNS infrastructure

•CDN or managed DNS routing layer

This means two users can see different answers at the same time without either browser being "wrong." They may be using different recursive resolvers, different cached entries, or different geo/latency routing responses.

Practical debugging

Use multiple vantage points when diagnosing DNS:

# Ask a specific resolver
dig @1.1.1.1 api.example.com

dig @8.8.8.8 api.example.com

# Ask for the authoritative path
dig +trace api.example.com

For frontend incidents, correlate DNS observations with browser network errors, CDN logs, regional traffic, and API availability. DNS can be the first failure, or it can only reveal an upstream routing mistake.

Negative Caching and NXDOMAIN

NXDOMAIN means the queried name does not exist. Resolvers may cache negative answers too.

That matters during rollout. If new-api.example.com is queried before the record exists, some resolvers can cache the negative result. After the record is created, those users may still see failures until the negative cache expires.

The negative caching lifetime is influenced by the zone's SOA (Start of Authority) record settings and resolver behavior.

Staff-level takeaway

Record creation can fail gradually for users even when the record now exists. If a launch depends on a new hostname, create and verify it before clients start requesting it.

CDN and Multi-Region Routing

DNS is often part of traffic steering, especially with CDNs and global load balancers.

Examples:

www.example.com      -> CDN edge network
api.example.com      -> global load balancer
assets.example.com   -> provider CNAME target

Routing policy may vary by geography, latency, health checks, or weighted rollout. This is useful, but it means DNS answers may legitimately differ across locations.

Trade-off

DNS failover can remove a bad endpoint from future lookups, but it cannot instantly pull users off cached answers. For high-availability systems, combine DNS with health checks, load balancer behavior, CDN shielding, origin failover, and client retry policy.

Frontend Performance Implications

DNS lookup time is part of connection setup for uncached hosts. It is most visible on cold page loads, new third-party origins, and high-latency networks.

What helps

•Reuse hostnames for critical assets where sensible.

•Avoid adding critical-path third-party origins casually.

•Use dns-prefetch for likely future DNS-only warming.

•Use preconnect only for truly critical origins because it performs DNS plus connection setup.

•Measure with browser network waterfalls and real-user data.

Condition-dependent claim

preconnect is not automatically faster overall. It can help when the warmed origin is actually needed soon, but it can waste sockets, CPU, and bandwidth if overused.

Failure Modes and Recovery Policy

Failure mode	User symptom	Recovery concern
stale cached record	some users hit old IP or region	wait for TTL or route old target safely
wrong CNAME target	assets or API unavailable	fix record and verify provider target
NXDOMAIN cached	new hostname fails for some users	negative cache may persist
DNS provider outage	healthy origins become unreachable	secondary DNS or provider resilience may matter
split resolver behavior	issue reproduces only on some networks	test multiple public and regional resolvers

Senior Interview Answer Pattern

Interview prompt	Strong response
Why did only some users fail after DNS migration?	Different resolvers and caches may still hold old answers.
Does lowering TTL now fix stale answers?	Not for entries already cached with an older longer TTL.
Why do third-party scripts affect DNS cost?	Each new critical hostname may require DNS and connection setup.
Is DNS failover instant?	No. It only affects future resolutions after caches refresh.

Key Takeaways

1DNS means Domain Name System; it is a distributed cache hierarchy, not a single lookup.

2TTL means Time To Live; it controls cache reuse and therefore change visibility.

3Cold DNS lookups can sit on the frontend request path before connection setup.

4CNAME chains, CDN routing, and multi-region policy make DNS behavior more than domain-to-IP mapping.

5Negative caching can make newly created hostnames fail temporarily after earlier NXDOMAIN responses.

6Short TTL improves agility but does not invalidate records already cached with longer TTL values.

7Staff-level answers connect DNS to latency, migration safety, failover windows, monitoring, and rollback policy.