Networking & Protocols
DNS: multiple-choice review
Crux Multiple-choice synthesis across the DNS unit — the resolver walk, glue, TTL and propagation, negative caching, DNSSEC failure modes, and encrypted transport.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make in a real DNS incident — a referral that looks wrong, a change that will not “propagate”, a SERVFAIL that hits only some users — not a definition to recite.
Goal
Confirm you can connect the resolver walk, caching and TTL semantics, DNSSEC validation, and encrypted transport into one model — the synthesis the individual lessons built toward.
Quiz
Completed
A resolver queries the .com TLD for shop.example.com and gets a response with an empty Answer section but NS and A records present. A junior calls it broken. Why is it actually correct?
Heads-up A TLD owns only the delegation, not the leaf data. It knows which authoritative server runs example.com and refers the resolver there; it never holds the shop.example.com A record.
Heads-up TLD servers never recurse for callers — RD is cleared on these iterative queries. They return only what they know plus a referral.
Heads-up Glue in Additional is the A/AAAA of the next-hop nameservers (so the resolver can reach them without a circular lookup), not the address of shop.example.com itself.
Quiz
Completed
You change an A record. A colleague sees the new value; you still get the old one for 40 more minutes, then it flips. Your manager says to wait 24-48 hours for 'propagation'. What is actually happening?
Heads-up There is no push and no wave. Authoritative servers never notify recursive caches; caches pull the new value only when their TTL expires.
Heads-up It is not throttling — it is just that your resolver's cache entry still had TTL remaining while your colleague's had expired. Same mechanism, different cache age.
Heads-up The stale entry lives in the upstream recursive resolver, not the browser. The browser cache is separate and short; restarting it does not flush the resolver.
Quiz
Completed
A flood of lookups hits an authoritative server for thousands of non-existent subdomains during an attack. Why does this barely raise authoritative load on a healthy setup?
Heads-up They do answer — with a signed NXDOMAIN/NODATA. The reason load stays low is that resolvers cache those negative answers, not that the server drops them.
Heads-up Resolvers forward unknown names normally — that is how anything new resolves. It is the cached negative answer that absorbs the repeat traffic.
Heads-up TTL applies to negative answers too. NXDOMAIN/NODATA caching duration is governed by SOA.MINIMUM precisely so typo storms do not flood the authoritative.
Quiz
Completed
After a KSK rollover last week your site is unreachable for ~30% of users with SERVFAIL, while the other 70% are fine. dig +cd returns the correct A record. What is the diagnosis?
Heads-up Every client resolves names. The split is between DNSSEC-validating and non-validating resolvers, not between users who do and do not use DNS.
Heads-up +cd disables DNSSEC checking and returns the correct A record — proving the data is fine on the authoritative server. The failure is in the validation chain, not the record.
Heads-up DoH encrypts transport between client and resolver; it has nothing to do with a broken DS-to-KSK chain. DNSSEC validation and encrypted transport are orthogonal.
Quiz
Completed
A privacy product wants both to hide which domains users resolve from network observers AND to prevent an off-path attacker from injecting a forged answer. Which combination actually delivers both?
Heads-up DoH hides and authenticates the channel to the resolver, but the resolver's own upstream answer can still be forged or wrong; only DNSSEC authenticates the record data end-to-end.
Heads-up DNSSEC signs data but sends it in plaintext over UDP/53; an eavesdropper still sees every domain queried. It gives integrity, not confidentiality.
Heads-up ECS leaks the client's subnet to upstream servers (the opposite of privacy) and TTL is about freshness, not confidentiality or integrity. Neither addresses the requirement.
Quiz
Completed
Resolution of a name intermittently returns SERVFAIL, and only for DNSSEC-signed or large responses; small plain UDP answers work. A firewall change shipped yesterday. What is the most likely cause?
Heads-up RRSIGs are not consumed per query. The size-correlated failure points at a transport/MTU issue — blocked TCP/53 or stripped EDNS0 — not a signing limit.
Heads-up DNSSEC works over UDP with EDNS0 advertising a large buffer; it falls back to TCP only when a response is truncated. The pattern points to blocked TCP/53 or a stripped OPT record.
Heads-up A corrupted cache would not selectively fail only large/signed responses right after a firewall change. The size correlation and the timing implicate the firewall, not the cache.
Recap
The through-line of the unit is one resolution model: a recursive resolver walks root to TLD to authoritative following referrals (NS in Authority, glue in Additional); every cache holds answers — positive and negative — only as long as the TTL permits, so “propagation” is just independent expiry; DNSSEC layers a signature chain from the root trust anchor down through DS/KSK/ZSK, and a broken link splits users along the validating/non-validating line; and encrypted transport (DoH/DoT/DoQ) hides queries but is orthogonal to DNSSEC’s integrity. Most production failures — stale records, NXDOMAIN floods, post-rollover SERVFAIL, blocked-TCP truncation — resolve back to one of those four mechanisms.