Table of Contents

DNS Resolver / Authoritative DNS Analysis Note #

This note captures the full step-by-step analysis for a DNS system that includes both authoritative serving and recursive resolution/caching: zone truth, record updates, delegation, cache state, and bounded-stale resolver responses.

Step 1 — Normalize #

Assume the baseline prompt is:

design a DNS system supporting authoritative DNS and recursive resolution
zone owners update DNS records
authoritative servers answer from zone truth
recursive resolvers cache upstream answers subject to TTL
delegation and NXDOMAIN/negative caching matter
system scales globally

Requirement	Actor	Operation	State touched	Priority
Zone owner creates/updates DNS record	Client	overwrite state	`S1` `update target` `ZoneRecord`	C1
Client queries authoritative DNS for name/type	Client	read source	`S1` `read source target` `ZoneRecord`	C1
Client queries recursive resolver for name/type	Client	read projection	`S1` `read projection target` `ResolverCacheEntry`	C1
Resolver fetches missing/expired answer from upstream/authoritative	System	async process	`S1` `hidden write target` `ResolverCacheEntry`	C1
Zone owner updates delegation / NS records	Client	overwrite state	`S1` `update target` `DelegationState`	C1
System publishes zone snapshot to authoritative servers	System	async process	`S1` `hidden write target` `AuthoritativeSnapshot`	C1
Client reads DNS status/analytics	Client	read projection	`S1` `read projection target` `DNSStatusView`	R2

Notes on normalization:

authoritative record updates are overwrite-state config changes
authoritative answer path is read source
recursive answer path is read projection
- resolver cache is a derived projection of authoritative/upstream truth
recursive refresh is async process
delegation state is explicit because it changes resolution path and authority
authoritative snapshot propagation is control-plane dissemination

This system is a composition of:

Origin Projection + Edge Delivery Plane
Control Plane + Data Plane

with authoritative DNS as source-of-truth serving and recursive DNS as cache/projection serving.

Step 2 — Critical Path Selection #

Requirement	Priority class	Why
Update DNS record	C1	changes authoritative naming truth
Answer authoritative query	C1	wrong answer breaks name resolution truth
Answer recursive query	C1	resolver must obey TTL/bounded staleness rules
Refresh resolver cache from upstream	C1	resolver correctness depends on valid refresh path
Update delegation state	C1	changes authority chain and resolution correctness
Publish authoritative snapshot	C1	stale auth servers can serve wrong zone data
Read DNS status/analytics	R2	operational only

Critical paths:

P1 update zone record
P2 answer authoritative query
P3 answer recursive query
P4 refresh resolver cache
P5 update delegation state
P6 publish authoritative snapshot

Step 3 — Primary State Extraction #

Candidate object label	Candidate source	Candidate needed for C1/R1?	Candidate decomposition action	Class	Primary?	Owner	Evolution	Scope kind	Scope value
ZoneRecord	direct noun	Yes	keep as candidate	entity	Yes	service	overwrite	relation	zone_id + name + type
DelegationState	direct noun	Yes	keep as candidate	entity	Yes	service	overwrite	instance	zone_id or delegation_scope
AuthoritativeSnapshot	hidden write target	Yes	keep as candidate	projection	Yes	service	overwrite	instance	auth_server_id + zone_id
ResolverCacheEntry	hidden write target	Yes	keep as candidate	projection	Yes	service	overwrite	relation	resolver_id + qname + qtype
NegativeCacheEntry	hidden write target	No	split candidate	projection	Yes	service	overwrite	relation	resolver_id + qname + qtype
DNSStatusView	derived read model	No	reject as UI artifact	projection	No	derived	overwrite	collection	zone_id or resolver_cluster

Minimal primary set:

ZoneRecord
DelegationState
AuthoritativeSnapshot
ResolverCacheEntry

Important modeling choices:

`ZoneRecord` #

Primary because:

it is the authoritative naming truth for a zone

`DelegationState` #

Primary because:

NS/delegation records determine which authority is responsible

`AuthoritativeSnapshot` #

Worth modeling because:

authoritative servers typically serve from propagated zone snapshots, not from a central DB on every query
versioning/freshness matter

`ResolverCacheEntry` #

Primary enough to model explicitly because:

recursive serving correctness depends on current cached answer, TTL, and validation state

`NegativeCacheEntry` #

Can be folded into ResolverCacheEntry with a result type if desired.

Step 4 — Hard Invariants #

Path	Tier	Type	Invariant statement
`P1` update zone record	HARD	ordering	Zone-record revisions are ordered by monotonic version within `(zone_id, name, type)`.
`P2` answer authoritative query	HARD	eligibility	`answer_authoritative_query` is valid only if returned record/delegation data is derived from current authoritative zone snapshot for that zone scope.
`P3` answer recursive query	HARD	freshness	Recursive answer reflects authoritative/upstream truth within TTL and cache-validation rules for `(qname, qtype)`.
`P4` refresh resolver cache	HARD	accounting	`ResolverCacheEntry` equals function of current upstream/authoritative answer and TTL semantics modulo bounded refresh delay.
`P5` update delegation state	HARD	ordering	Delegation revisions are ordered by monotonic version within delegation scope.
`P6` publish authoritative snapshot	HARD	freshness	`AuthoritativeSnapshot(auth_server, zone)` reflects authoritative zone truth within configured propagation bound.

What matters most:

authoritative answers must come from correct zone version
recursive answers must obey TTL / negative caching / refresh rules
delegation changes must move monotonically
auth server snapshots must converge to current zone truth

Step 5 — Execution Context #

Field	Value	Why
Topology	single service distributed	one logical DNS platform with authoritative and recursive serving fleets
Write coordination scope	per object scope	correctness is per zone record, delegation scope, auth snapshot, and resolver cache entry
Read consistency target	bounded stale allowed	recursive caches and authoritative snapshots are naturally bounded-stale projections
Holder model	none	no lease-like per-request ownership is central
Compensation acceptable?	No	wrong DNS answers are not compensable correctness failures

Derived:

bounded_staleness_allowed = true
exclusive_claim_required = false
guarded_by_current_state = true

This implies:

authoritative zone truth plus propagated serving snapshots
bounded-stale recursive cache serving
versioned zone/snapshot propagation

Step 6 — Deterministic Mechanism Selection #

Path	Write shape	Base mechanism	Required companions
`P1` update zone record	overwrite current value	CAS on version	zone version
`P4` refresh resolver cache	overwrite current value	single writer cache refresh or CAS on version	TTL / expiry metadata
`P5` update delegation state	overwrite current value	CAS on version	delegation version
`P6` publish authoritative snapshot	overwrite current value	single writer snapshot publication	snapshot version

Hot paths:

P2 authoritative answer is a read path
P3 recursive answer is a read path

Why these fit:

zone and delegation data are authoritative current-state config
recursive cache entries are current-state projections with TTL
authoritative snapshots are versioned propagated projections

Step 7 — Read Model / Source of Truth #

Concept	Truth	Read path	Rebuild path
`C1` zone record truth	`ZoneRecord`	read source directly	authoritative zone store
`C2` delegation truth	`DelegationState`	read source directly	authoritative delegation store
`C3` authoritative server local zone view	`AuthoritativeSnapshot`	materialized view	rebuild from latest zone/delegation truth
`C4` recursive cache entry	`ResolverCacheEntry`	materialized view	refresh from upstream/authoritative answer
`C5` DNS status/analytics	derived	materialized view	recompute from primary state

Important point:

authoritative query path should read local authoritative snapshot
recursive query path should read local resolver cache entry if valid
neither hot path should synchronously depend on central control-plane state

Step 8 — Failure Handling #

Path	Retry	Competing writers	Crash after commit	Publish failure	Stale holder
zone/delegation update	retry with version	stale update loses CAS	committed zone state survives crash if persisted	snapshot propagation may lag	n/a
authoritative snapshot publication	retry with snapshot version	older snapshot loses to newer version	auth server keeps last good snapshot until refresh	failed push retried or pulled	n/a
recursive cache refresh	retry with current TTL/validation metadata	latest valid refresh wins	cache refresh crash just delays refresh; next query/refresher retries	upstream fetch may fail and cache may serve stale/negative answer per policy	n/a
authoritative answer	client retries are network-level	multiple auth nodes can answer from same zone snapshot version	one auth node crash affects only local requests	n/a	stale snapshot bounded by propagation/version discipline
recursive answer	client retries are network-level	many resolvers can answer from their own valid cache entries	one resolver crash affects local cache only	upstream lookup retry/backoff	stale cache bounded by TTL/refresh policy

What matters most:

authoritative snapshots move monotonically by zone version
recursive caches obey TTL and negative caching rules
stale answers are bounded by explicit freshness policy

Step 9 — Scale Adjustments #

Hotspot	Type	First response
massive global query volume	read hotspot	add more anycast edge/resolver capacity and keep hot paths local
hot zone record churn	fan-out hotspot	batch zone updates and publish incremental zone snapshots
cache-miss storms on popular names	contention hotspot	request coalescing and stale-while-revalidate patterns
negative-cache churn	read hotspot	compact negative cache representation and respect TTLs carefully
snapshot fanout to auth fleet	fan-out hotspot	incremental zone diff propagation and pull-on-version-miss
analytics/status reads	read hotspot	derived views only

What scales well:

authoritative and recursive serving both scale horizontally with local snapshots/caches
central zone truth remains narrow and versioned

What fails first:

cache-miss storms
zone update fanout bursts
stale snapshot propagation under very high change rate

Canonical design conclusion:

archetype composition:
- Origin Projection + Edge Delivery Plane
- Control Plane + Data Plane
primary truth:
- ZoneRecord
- DelegationState
- AuthoritativeSnapshot
- ResolverCacheEntry
hot paths:
- authoritative answer from local zone snapshot
- recursive answer from local resolver cache under TTL

Concrete Substrate #

authoritative zone truth in strongly consistent zone-management store
zone publication control plane in Go/Java
authoritative DNS fleet serving from local versioned zone snapshots
recursive resolver fleet serving from local cache with TTL/negative-cache semantics
snapshot propagation via watch streams / pull-on-version-miss / signed zone transfer

Operation Layer #

PutZoneRecord(zone_id, name, type, value, ttl, expected_version?)

entry point: zone-management API
authoritative decider: zone store owner
transition: overwrite ZoneRecord

PutDelegation(zone_id, ns_records, expected_version?)

entry point: zone-management API
authoritative decider: delegation store owner
transition: overwrite DelegationState

internal zone publication

rebuild latest AuthoritativeSnapshot(zone_id, version)
publish to authoritative servers

AnswerAuthoritative(qname, qtype)

entry point: authoritative DNS node
authoritative decider: local AuthoritativeSnapshot
transition: none
response: DNS answer/delegation/NXDOMAIN from local zone snapshot

ResolveRecursive(qname, qtype)

entry point: recursive resolver
authoritative decider: local ResolverCacheEntry if valid, otherwise upstream resolution path
transition: optional cache refresh/update
response: cached or freshly resolved answer

internal cache refresh

validate TTL/expiry
overwrite ResolverCacheEntry

Entry Point vs Decider vs Responder #

Path	Entry point	Authoritative decider	Physical responder	Logical responder
authoritative answer	authoritative DNS node	local authoritative snapshot	authoritative node	DNS platform
recursive answer	resolver node	local resolver cache / upstream resolution path	resolver node	DNS platform
zone/delegation update	zone-management API	zone/delegation store owner	control-plane node	DNS platform
zone snapshot publication	auth server / control plane	snapshot publisher	control/data-plane	DNS platform
cache refresh	resolver node	local refresh worker + upstream answer	resolver node	DNS platform

Concrete HLD #

Main components:

zone-management API
authoritative zone/delegation store
zone snapshot publication layer
authoritative DNS fleet
recursive resolver fleet
DNS status/analytics views

Short interview version #

“I’d design DNS as authoritative zone truth plus bounded-stale serving layers. Zone records and delegation state are authoritative, then published as versioned snapshots to the authoritative DNS fleet. Recursive resolvers serve from local cache entries under TTL and negative-caching rules, refreshing from upstream when entries expire or miss. The hot paths are fully local reads, while control plane handles versioned zone updates and snapshot publication.”