DNS
DNS is a distributed, delegated, heavily cached database whose answers often steer traffic. Its operational behavior is defined as much by recursive resolvers and caches as by authoritative servers. Senior candidates understand record types, resolution paths, TTL and negative caching, delegation, DNSSEC, encrypted resolver transports, and why DNS failover is neither instant nor a complete health-routing system.
How to use this chapter
- Read the mental model and mechanics without taking notes.
- Close the page and explain the topic aloud in five minutes.
- Work the quantitative example on paper.
- Answer the question ladder without revealing the answer signals.
- Complete one design drill and score yourself with the senior checklist.
Learning objectives
- Trace iterative and recursive resolution from stub resolver to authoritative answer.
- Explain zones, delegations, authoritative servers, recursive resolvers, and caching.
- Use A/AAAA, CNAME, NS, SOA, MX, TXT, SRV, CAA, and alias-like provider records appropriately.
- Reason about TTL, negative caching, stale answers, propagation, and failover timing.
- Discuss DNSSEC, DoH/DoT/DoQ, split-horizon DNS, and rebinding/security concerns.
- Design resilient global DNS and troubleshoot partial resolution failures at senior level.
Mental model
DNS maps names to typed data through delegation. A client usually asks a recursive resolver, which follows cached or newly discovered referrals from the root to a top-level domain and then an authoritative server. The recursive resolver caches both positive and negative answers. The authoritative service controls future answers, but it cannot recall answers already cached elsewhere.
Core mechanics
Resolution path and roles
A stub resolver on the client sends a recursive query to a configured recursive resolver. The resolver answers from cache or performs iterative queries to authoritative infrastructure. Root and TLD servers provide delegations; the domain’s authoritative server returns final records or another delegation.
Separate resolver failure from authoritative failure. A public authoritative service can be healthy while one ISP resolver has stale or poisoned cache. Conversely, a local resolver can answer cached data during an authoritative outage until TTL expires.
Zones, delegation, and records
A zone is an administrative portion of the namespace described by records and an SOA. NS records delegate authority. Glue records may be needed to break circular dependency when nameserver names lie within the delegated domain.
A and AAAA map to IPv4/IPv6. CNAME aliases one name to another but has restrictions at a zone apex and cannot generally coexist with other data at the same owner name. MX routes mail, TXT carries verification/policy data, SRV includes service/port/priority/weight, and CAA constrains certificate authorities. Cloud “alias” records are provider features, not a universal DNS record type.
Caching, TTL, and negative answers
TTL specifies how long a resolver may cache a record. Lower TTL improves potential steering speed but increases authoritative query volume and does not guarantee every client honors the value exactly. Raising TTL before a stable event can reduce load; lowering it must happen at least one old-TTL interval before a planned change to affect existing caches.
NXDOMAIN and no-data responses can also be cached according to negative-caching rules. Accidentally publishing NXDOMAIN can therefore persist after the record is restored. Some resolvers serve stale data during upstream failures, improving availability at the cost of freshness.
Load balancing and global traffic steering
DNS can return multiple addresses, weighted answers, geolocation/latency-based choices, or failover targets. Clients and recursive resolvers choose, cache, and sometimes reorder answers. DNS sees the resolver’s location unless client-subnet mechanisms or other signals are used, so resolver geography may not match the user.
DNS is best for selecting an edge or region, followed by an L4/L7 load balancer for fine-grained health and balancing. Anycast can route the same IP prefix to multiple sites and complements DNS, but route convergence and stateful flows require careful design.
DNSSEC and encrypted DNS
DNSSEC signs DNS data so validating resolvers can verify authenticity and denial of existence. It does not encrypt queries and does not make an incorrect but validly signed record correct. Key rollover, delegation-signer records, and clock/configuration mistakes introduce operational risk.
DNS over TLS, HTTPS, or QUIC encrypts transport between a client and resolver. It improves privacy against on-path observers for that segment but shifts trust to the resolver and can bypass local network policy. It does not replace DNSSEC’s data-origin authentication.
Split-horizon and internal DNS
Split-horizon DNS returns different answers based on network or resolver context, often for internal/private services. It supports private routing but complicates debugging, VPN behavior, certificate validation, and disaster recovery. Internal names should have clear ownership, lifecycle, and collision policy.
Service discovery systems may use DNS records with short TTLs, but applications and language runtimes often cache differently. For rapidly changing endpoints, combine DNS with client-side discovery or a proxy that actively tracks membership.
Security and abuse
DNS is used in amplification attacks because small spoofed queries can cause larger UDP responses. Authoritative and recursive services need rate controls, source validation in networks, and recursion restricted to intended clients. DNS rebinding can cause a browser-resolved name to change to an internal address, so applications must validate origins/hosts and not treat DNS resolution alone as authorization.
Domain takeover, registrar compromise, expired domains, dangling CNAMEs, and unauthorized nameserver changes can bypass otherwise strong application security. Protect registrar accounts, use change locks/MFA, monitor delegation and certificates, and remove stale records.
Decision table
| Decision | Prefer the first option when… | Prefer the second option when… | Senior caveat |
|---|---|---|---|
| Low TTL vs high TTL | Rapid planned changes and fine steering are valuable. | Stable records, resolver load, and resilience to authoritative outages dominate. | Lower early before a change; it does not affect already cached old TTLs. |
| DNS balancing vs anycast/LB | Coarse endpoint/region selection and simple global control are enough. | Fast per-flow health, stable IP, or fine balancing is required. | Often combine DNS for region selection with anycast or regional LBs. |
| A/AAAA vs CNAME | Direct address control and fewer lookups matter. | Delegating endpoint ownership to another name is useful. | Apex restrictions, chain depth, TTLs, and dangling aliases matter. |
| Public vs split-horizon DNS | The same globally reachable endpoint should resolve everywhere. | Internal/private routes and differentiated answers are required. | Test VPN, roaming clients, failover, and certificate behavior. |
| DNSSEC vs unsigned | Authenticity against forged DNS data is required and operations can manage keys. | Simplicity is prioritized and other controls are accepted. | DNSSEC failures can become hard failures for validating clients; automate rollover and monitor. |
| Resolver transport: classic vs encrypted | Local network simplicity/policy and broad compatibility dominate. | Privacy and authenticated resolver transport are required. | Encrypted DNS changes trust/visibility; define resolver discovery and enterprise policy. |
Quantitative reasoning
Failure modes and production signals
| Failure mode | What users see | Likely cause | Mitigation / design response | Useful signals |
|---|---|---|---|---|
| Stale cached address | Some clients reach old or failed endpoint | TTL/client cache/existing connection | Keep old endpoint alive during drain, retry/re-resolve, lower TTL in advance | Queries/traffic by answer, connection age, resolver samples |
| NXDOMAIN cached | Restored name still fails for a subset | Negative caching after missing record/delegation | Avoid destructive changes, wait/serve alternate name, monitor negative TTL | NXDOMAIN rate, SOA negative TTL, resolver tests |
| Delegation failure | Domain or subdomain fails globally/partially | Bad NS/glue/DS configuration | Multiple authoritative providers, staged changes, DNS lint and probes | Delegation checks from multiple resolvers, SERVFAIL rate |
| DNSSEC validation failure | Validating resolvers return SERVFAIL | Expired signatures, DS mismatch, key rollover error | Automated signing/rollover, monitor chain, emergency procedure | Validation status, signature expiry, DS/DNSKEY parity |
| Resolver-local issue | One ISP/corporate network cannot resolve | Poisoned/stale cache, filtering, transport issue | Test alternate resolvers, coordinate purge, provide fallback only where safe | Success by ASN/resolver, answer comparison, DoH/DoT path |
| Dangling alias takeover | Traffic or trust points to third party | CNAME target deprovisioned but DNS remains | Inventory/ownership checks, remove aliases before resources, takeover monitoring | Dangling record scans, certificate transparency, DNS changes |
Senior-level lenses
DNS is eventual control, not instant failover
State which traffic changes: new lookups, new connections, or all active sessions. Combine low TTL with active health routing, endpoint overlap, client reconnect/re-resolution, and rollback. For stateful services, moving traffic without moving or reconciling state can make availability worse.
Resolver behavior is part of the client architecture
Browsers, operating systems, JVMs, mobile SDKs, proxies, and service meshes can cache or refresh names differently. Define whether the application pins addresses for a pool’s lifetime and whether it re-resolves on failure. Test real runtimes rather than assuming RFC-perfect behavior.
Multiple DNS providers need consistency
Multi-provider authoritative DNS can reduce provider risk but introduces configuration drift and differing feature semantics. Use a source-of-truth pipeline, compare served zones, stage changes, and avoid provider-specific records that cannot be represented consistently unless the failover plan accounts for them.
Health checks can cause flapping
Aggressive DNS failover based on a few probes can oscillate traffic or move load into an underprovisioned region. Use multi-vantage checks, thresholds, hold-down periods, capacity awareness, and manual safety controls for large shifts.
Names are security-sensitive dependencies
Registrar, registry, DNS provider, signing keys, and certificate issuance form a trust chain. Protect administrative APIs and audit changes. A resilient application stack cannot compensate for a hijacked delegation.
Separate naming from placement
Stable logical names let placement change, but do not overload one name with incompatible semantics. Version or scope names where protocols, tenants, or trust boundaries differ, and avoid exposing physical hostnames as durable public contracts.
Interview question ladder
What is the difference between a recursive resolver and an authoritative server?
Show strong-answer signals
Recursive resolver obtains/caches answers for clients; authoritative server serves data for zones it controls.
What does a DNS TTL mean?
Show strong-answer signals
How long a resolver may cache the record, not a guaranteed propagation time or lease on existing connections.
What is a CNAME?
Show strong-answer signals
An alias from one domain name to another; discuss extra lookup, no other data at same owner, and apex/provider-alias caveat.
Why can DNS changes take longer than the new TTL?
Show strong-answer signals
Old answers were cached with the previous TTL; clients/runtimes may cache; negative caching and existing connections persist.
How does DNS-based load balancing differ from an L7 load balancer?
Show strong-answer signals
DNS gives cached endpoint choices before connection and has limited health/control; L7 sees requests, active health, headers, retries, and can balance per request/connection.
What problem does DNSSEC solve, and what does it not solve?
Show strong-answer signals
Authenticity/integrity of DNS data and authenticated denial; not confidentiality, endpoint availability, or correctness of signed configuration.
Plan a zero-downtime migration from one CDN to another.
Show strong-answer signals
Inventory records/certificates, lower TTL early, dual-serve and validate content/cache behavior, weighted traffic, monitor by resolver/ASN, keep old CDN during TTL/connection drain, rollback, then raise TTL.
A hostname returns SERVFAIL only from some public resolvers after a DNSSEC key rotation. Diagnose.
Show strong-answer signals
Check DS at parent vs DNSKEY, signatures/expiry/clock, algorithm support, propagation to all authoritative servers/providers, delegation, and validation traces.
Design DNS for a global API with regional data residency.
Show strong-answer signals
Use tenant/user placement metadata and region-scoped endpoints; avoid routing writes purely by resolver geography; authenticate tenant, enforce residency at app/data layer, health/capacity-aware DNS, and failover policy that preserves compliance.
How do you prevent DNS failover from overloading the surviving region?
Show strong-answer signals
Reserve degraded capacity, weighted gradual shift, capacity-aware health, admission control, shed noncritical work, warm caches, retry budgets, and hold-down/manual guardrails.
Design authoritative DNS across two providers without configuration drift.
Show strong-answer signals
Declarative source of truth, portable record model, CI validation/lint, signed change pipeline, compare AXFR/API/queries, canary records, independent monitoring, DNSSEC key/DS strategy, break-glass.
A mobile app pins DNS results for hours to save battery. Design an emergency endpoint migration.
Show strong-answer signals
Multiple bootstrap endpoints, application-level redirect/config with signatures, connection failure triggers refresh, bounded cache max age, staggered rollout, backward-compatible certificates/protocol, and app-version realities.
Design drills
Design DNS and connection behavior for an API active in two regions. A whole region can fail, but writes have a home region. Specify TTLs, health probes, capacity guardrails, client retry/re-resolution, and data semantics.
What the interviewer is testing
Combining DNS control with state consistency and failure-safe traffic movement.
A cluster has 100,000 frequently changing service instances. Compare short-TTL DNS, client-side discovery, and a local proxy. Address resolver load, stale endpoints, connection pools, and rollout.
What the interviewer is testing
Understanding DNS limits and selecting a layered discovery architecture.
Create a threat model and operational checklist for a high-value public domain: registrar, DNS provider, DNSSEC, certificates, dangling records, email records, and emergency recovery.
What the interviewer is testing
DNS as a security control plane, not just a lookup mechanism.
Common weak answers and how to improve them
“Set TTL to zero for instant failover.”
Show the stronger answer
Resolvers/clients may impose caching, authoritative load rises, and active connections remain; design overlap and client recovery.
“DNS propagation takes 48 hours.”
Show the stronger answer
Explain caching based on previous TTL, delegation, negative caching, and resolver/client behavior instead of a universal timer.
“Use round-robin DNS for load balancing.”
Show the stronger answer
Discuss caching, client selection, health, unequal capacity, resolver geography, and regional LBs.
“DNSSEC encrypts DNS.”
Show the stronger answer
DNSSEC authenticates signed data; DoH/DoT/DoQ encrypt resolver transport.
“CNAME the root domain.”
Show the stronger answer
Standard CNAME has apex/coexistence restrictions; provider alias/flattening features are nonstandard abstractions.