Module 09 — Performance, Reliability & Security at Scale
Updated 20 August 2026
The last module. How 13 root server names become a thousand machines; what DNS load balancing can and cannot do; TTL strategy for cutovers; amplification, reflection and rate limiting; what the anti-spoofing measures really buy; encrypted DNS; and the incident playbooks that tie all nine modules together.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
Prerequisite: Modules 01–08. This module is mostly a synthesis — it assumes the whole track.
Part A · Making DNS fast and available
A1 · Anycast — how 13 names become a thousand servers
You dial it from Penang and the nearest Penang branch picks up. Someone dials the same number in Johor and gets Johor. Nobody was told a different number and nobody chose a branch.
And when a branch closes for the day, calls simply start ringing at the next one — instantly, with no announcement. That is why anycast gives you the fast failover a DNS record change never can: the number never changed, so nobody is holding an old one.
Module 01 A2 promised an explanation: there are 13 root server identities, and over a thousand physical machines answering on those same 13 addresses. Anycast is the mechanism.
Three properties follow, and they are exactly what DNS needs:
- Latency drops, because every user reaches a nearby instance without any per-user decision being made
- Failure is automatic — an instance that stops announcing the route simply disappears, and traffic re-converges with no DNS change and no TTL to wait out
- DDoS traffic is divided across every site rather than concentrated on one
And note point 2 carefully, because it is the answer to Module 08 A3's limitation. Anycast provides the fast failover that DNS records cannot: no cache holds a stale answer, because the address never changed.
🧪 Exercise A1.1 — Prove you are talking to a nearby instance
# the same address, different answer depending on where you are
dig @a.root-servers.net hostname.bind CH TXT +short
dig @k.root-servers.net hostname.bind CH TXT +short
# compare the latency to a root server with a distant unicast host
dig @a.root-servers.net . SOA +noall +stats | grep 'Query time'✅ Expected result — click to reveal
$ dig @k.root-servers.net hostname.bind CH TXT +short
"ns2.lon.k.ripe.net"
;; Query time: 8 msecYour instance name will be different — that is the entire point.
hostname.bind in the CH (Chaos) class is a diagnostic convention, not normal DNS. Many anycast operators answer it with the identity of the specific instance you reached. Query the same address from Singapore and Frankfurt and you get different names back.
Single-digit milliseconds to a *root server* — one of thirteen addresses serving the entire internet. That number is only possible because there is an instance near you. Without anycast, most of the world would be 150–300 ms from the nearest root.
This is also why "there are only 13 root servers" is the trap from Module 01. Thirteen addresses, over a thousand machines, and the question is really testing whether you know the difference between a name, an address, and a server.
A2 · DNS load balancing, and its real limits
He alternates politely: table 1, table 2, table 3. Then a coach party of forty arrives, is told "table 4", and all forty go to table 4.
That is DNS load balancing. It shares out the people who ask, not the work — and one resolver serving a million users counts as one person asking.
| Technique | What it really does |
|---|---|
| Round robin | Multiple A records, rotated per response. Distributes lookups, not load |
| Weighted | Provider-side probability per record. Good for canaries; still coarse |
| Latency / GeoDNS | Answer chosen by the resolver's apparent location |
| Health-checked failover | Withdraws a record when a check fails. Bounded below by the TTL |
| Anycast | Not DNS at all. The only one with sub-second failover |
- It distributes lookups, not requests. One resolver serving a million users caches one answer and sends them all to the same address. Cache hit rate, not user count, decides the split
- The client chooses. Module 02 A1: an RRset is unordered, and the client picks. getaddrinfo may reorder or prefer IPv6 regardless of what you sent
- It cannot see load. DNS knows nothing about connections, CPU or queue depth — only whether a health check passed
- Withdrawal is slow. TTLs, resolver floors, serve-stale and application caches all outlive your decision
So the honest positioning: DNS distributes traffic at the coarse, geographic, slow layer. Real balancing happens at the load balancer or in the client. Saying that in an interview is worth more than listing the policies.
A3 · TTL strategy
A well-stocked cupboard means you can survive a week with the shops shut. It also means changing your diet takes a week to show.
A long TTL is that cupboard — free insurance if your servers go down. A short one is agility, and it comes with a hard dependency on the shops being open right now. You want the cupboard full, except during the week you are deliberately changing things.
| Record | Typical TTL | Reasoning |
|---|---|---|
| Apex / www in steady state | 300–3600 | Balance query volume against agility |
| Anything mid-migration | 60 | Set it 48h before, not on the day |
| NS records | 86400+ | Rarely change; long TTLs keep you resolvable if your servers wobble |
| MX | 3600+ | Mail retries anyway. Agility buys little |
| SOA MINIMUM | 300–900 | Governs how long a "no" sticks after you create a name |
So the rule is not "low TTLs are agile and good". It is: long by default, low deliberately and temporarily around a planned change, then back up.
Part B · Attacks and defences
B1 · Amplification and reflection
Two things happen. Every reply goes to the victim, not to you — and your name appears nowhere. And each tiny card comes back as a thick catalogue, so a little effort from you buries them.
That is reflection and amplification. Both work only because nobody checks that the sender address is real.
Diagram source
flowchart LR
A["attacker<br>small query<br>~60 bytes"] -->|"SOURCE ADDRESS<br>FORGED as the victim"| S["your open resolver<br>or authoritative server"]
S -->|"large response<br>up to ~4000 bytes"| V["THE VICTIM<br>never asked for it"]
A -.->|"repeat from<br>thousands of hosts"| S
style A fill:#ef4444,color:#fff
style V fill:#f59e0b,color:#fff
style S fill:#8b5cf6,color:#fffReflection — the response goes to a forged source address, so the victim is attacked by your server and the attacker's address never appears.
Amplification — the response is far larger than the query, so the attacker multiplies their bandwidth. ANY queries and DNSSEC-signed responses were the favourite tools, which is exactly why RFC 8482 exists and why Module 02 A2's ANY returns a joke HINFO record.
And UDP is what makes it possible at all. No handshake means no proof the source address is real. This is Module 04 B1's trade-off showing its bill.
| Defence | What it does |
|---|---|
| recursion no on authoritative servers | Module 05's first line. Stops you being an open resolver at all |
| allow-recursion limited to your own ranges | For resolvers that must recurse, serve only your users |
| Response Rate Limiting (RRL) | Caps identical responses per source per second. Truncates rather than drops, so real clients retry over TCP |
| Minimal responses | Smaller answers, less amplification |
| RFC 8482 ANY handling | Removes the largest amplification lever |
| BCP 38 source filtering | The real fix, and not yours to deploy — networks should not emit forged source addresses |
B2 · Cache poisoning, revisited — what the defences actually buy
Every measure in the table below except the last one adds digits to the PIN. Guessing gets slower, sometimes impossibly slow — but it is still a guessing game, and the attacker can keep trying for free.
The last row changes the game rather than the odds: a forgery is no longer unlikely, it is detectable.
| Measure | What it actually achieves |
|---|---|
| Transaction ID (16 bits) | The original. Alone, guessable in seconds under a flood |
| Source port randomisation | ≈2³² combinations. The 2008 emergency fix, and silently undone by NAT that rewrites ports predictably |
| 0x20 case randomisation | ~1 bit per letter, free, occasionally breaks non-compliant servers |
| DNS cookies | 64 bits of shared state. On by default in BIND 9.18 — you saw one in Module 05 A4.1 |
| Fragmentation avoidance | Closes the bypass where later fragments carry no ID or port at all |
| DNSSEC | The only one that changes the category — forged data becomes detectable, not merely improbable |
And the honest caveat that a strong candidate adds: DNSSEC protects the path to the validating resolver, not the last hop to the client. That hop is what DoT, DoH and DoQ are for — and they solve a different problem, which is B3.
B3 · Encrypted DNS — DoT, DoH, DoQ
Sealing stops the postman reading it. Signing proves who wrote it. They are completely different protections and neither substitutes for the other.
DNSSEC signs. DoT and DoH seal. A sealed envelope from a liar still contains lies — privately, and beautifully protected from anyone else finding out.
| Protocol | Port | Character |
|---|---|---|
| DoT | 853 | Plain DNS inside TLS. Distinguishable on the network, so it can be blocked or allowed by policy |
| DoH | 443 | DNS inside HTTPS. Indistinguishable from web traffic — which is the feature and the controversy |
| DoQ | 853/UDP | Over QUIC. Avoids TCP head-of-line blocking; the newest of the three |
DNSSEC proves the data is genuine, and does not hide it. DoT/DoH/DoQ hide the conversation, and prove nothing about the data — an encrypted channel to a lying resolver returns lies, privately.
You want both, and they operate at different points: DNSSEC from the zone to the validating resolver, encryption from you to that resolver.
The operational tension worth naming: DoH on port 443 bypasses the enterprise resolver entirely. A browser with DoH enabled ignores your split-horizon setup from Module 08, your internal zones, your filtering and your logging — and it does so invisibly, because the traffic looks like HTTPS. That is why "disable DoH in managed browsers" is a real enterprise policy and why it is genuinely contested.
B4 · Observability
Both tell you there is a problem. Only one gives you time to do something about it.
The two readings almost nobody takes are in the callout below — and both catch conditions that show no symptoms at all right up until the day everything stops.
| Signal | What it tells you |
|---|---|
| Query rate by RCODE | A rising NXDOMAIN share means a search-list problem, a typo'd deployment, or malware beaconing |
| SERVFAIL rate | Upstream failures, or DNSSEC validation going bad. The metric that catches an expired RRSIG |
| Cache hit ratio | A sudden drop means a restart, an eviction problem, or a flood of unique names |
| Latency percentiles | p99, not the mean. DNS failures present as latency — Module 06 B1's 5-second timeouts hide in an average |
| Serial agreement across servers | Module 05 D1's check. Catches missed serial bumps, failed transfers and expired zones at once |
| RRSIG expiry countdown | Alert days before. By the time validation fails your domain is already dark |
| Response size trend | Module 04 D2. Records accumulate until ordinary answers need TCP |
Part C · Incident playbooks
C1 · The four-question triage
You check for breathing before you worry about the broken arm. Not because the arm does not matter, but because one question rules out the possibility that everything else is irrelevant.
That is why "did anything answer at all?" comes first here. It is the only question that can take DNS off the list entirely.
Diagram source
flowchart TD
S["a DNS incident"] --> Q1{"1. is there a<br>status: line at all?"}
Q1 -->|"no"| NET["network / firewall<br>timed out = silent drop<br>refused = nothing listening<br>MODULE 01 D3"]
Q1 -->|"yes"| Q2{"2. what RCODE?"}
Q2 -->|"REFUSED"| POL["policy, not fault<br>wrong server or ACL<br>MODULE 01 D3"]
Q2 -->|"SERVFAIL"| Q3{"3. does +cd fix it?"}
Q3 -->|"yes"| DS["DNSSEC validation<br>check RRSIG expiry FIRST<br>MODULE 07 D3"]
Q3 -->|"no"| Q3b["ask a second resolver<br>one fails = that resolver<br>all fail = zone/delegation<br>MODULE 03 D1"]
Q2 -->|"NXDOMAIN / NODATA"| Q4{"4. does dig agree<br>with getent?"}
Q4 -->|"no"| LOCAL["/etc/hosts, nsswitch,<br>search list, split horizon<br>MODULE 06 D1"]
Q4 -->|"yes"| AUTH["query the AUTHORITATIVE servers<br>do they all agree? same serial?<br>MODULE 05 D1"]
style NET fill:#ef4444,color:#fff
style DS fill:#ef4444,color:#fff
style POL fill:#8b5cf6,color:#fff
style LOCAL fill:#f59e0b,color:#fffThe ordering is deliberate. Question 1 is first because it is the only one that removes DNS from the investigation entirely. Question 4 is last because local-resolution problems are the ones people never suspect and always find last.
C2 · Migration playbook
You redirect the post weeks before, not on the day. You check that letters actually start arriving. And you do not hand back the old keys the same week, because some people will keep writing to the old address no matter what you told them.
The last row of the table below is that final point, and it is the one that turns a clean move into a mess.
| When | Do | Module |
|---|---|---|
| T-7d | Export the zone from the provider API. Inventory alias records and routing policies — they are invisible to dig | 08 A2 |
| T-7d | Check response sizes and confirm TCP/53 works end to end | 04 D2 |
| T-48h | Read the current TTL, lower it, then wait out the old TTL | 03 D3 |
| T-24h | If DNSSEC: publish the new DS only after the new servers serve the signed zone correctly | 07 C3 |
| T-0 | Make the change | — |
| T+1m | Query every authoritative server — same data, same serial? | 05 D1 |
| T+2m | dig +trace — bypasses every cache including serve-stale, which can hide a broken cutover | 03 D1 |
| T+5m | Poll several public resolvers until all agree. Read the TTLs to state the remaining wait | 03 B5 |
| T+10m | Delegation check: parent NS = child NS, and every server answers with aa | 03 D2 |
| T+1d | Raise the TTL back up | 09 A3 |
| T+7d | Only now decommission the old endpoint | 03 B4 |
Part D · Putting it together
D1 · How this all fits — the whole track in one picture
Diagram source
flowchart TD
U["user / application<br>MODULE 06<br>hosts, nsswitch, ndots"] --> R["RECURSIVE RESOLVER<br>MODULE 03<br>walks the tree, caches everything"]
R -->|"MODULE 04<br>UDP first, TCP on tc<br>EDNS 1232"| AUTH["AUTHORITATIVE SERVERS<br>MODULE 05<br>primary + secondary, serials, TSIG"]
AUTH --> ZONE["THE ZONE<br>MODULE 02<br>RRsets, TTLs, CNAME rules"]
ZONE --> SIGN["MODULE 07<br>DNSSEC: RRSIG, DS, NSEC3<br>signatures EXPIRE ON A DATE"]
R -.->|"MODULE 09<br>anycast, RRL, DoT/DoH"| SCALE["reliability + security layer"]
AUTH -.->|"MODULE 08<br>Route 53, private zones<br>CoreDNS, ndots:5"| CLOUD["cloud + cluster layer"]
style R fill:#8b5cf6,color:#fff
style AUTH fill:#22c55e,color:#fff
style SIGN fill:#ef4444,color:#fff
style SCALE fill:#f59e0b,color:#fffFive ideas the whole track reduces to.
- DNS is a distributed, delegated, cached database. Every behaviour that surprises you is one of those four words.
- The cache is where the surprises live. Nothing propagates; independent timers expire independently, and resolvers may ignore your TTL in both directions.
- OK never means correct. A zone file that loads, a server that answers, a +short that prints something — none of those is a test.
- Read status: before anything else. Five outcomes, five owners, and one word tells you which.
- Everything except DNSSEC is a probability argument. Only cryptography turns "unlikely to be forged" into "provably not forged".
D2 · Production practice
| Habit | Why |
|---|---|
| Use anycast for anything needing fast failover | It is the only mechanism here with sub-second recovery, because the address never changes and no cache goes stale |
| Long TTLs by default, low deliberately and temporarily | A long TTL is free resilience if your nameservers wobble; a low one is a hard dependency on them being reachable now |
| Do not use DNS as a load balancer | It distributes lookups not requests, cannot see load, and the client chooses. Balance at the load balancer |
| recursion no on authoritative servers, allow-recursion scoped on resolvers | Stops you being a reflector. The oldest finding in DNS auditing and still the most common |
| Enable RRL on public authoritative servers | Truncates rather than drops, so real clients retry over TCP and spoofed sources cannot |
| Alert on RRSIG expiry approaching and serial agreement | The two failures in this whole track that are completely silent until they are outages |
| Track p99 latency, not mean | DNS faults present as latency, and 5-second timeouts vanish into an average |
| Decide a DoH policy deliberately | A browser with DoH enabled bypasses your split-horizon, filtering and logging, invisibly, on port 443 |
| Keep the old endpoint alive a week past a migration | Serve-stale and application caches keep a tail of clients on the old address long past any TTL |
| Keep zones in Git, apply through CI, with named-checkzone as a gate | Review, history, mechanical serial bumps, and the diff between snapshots is where the findings are |
D3 · Capstone exercise — the whole track
Brief. You have inherited a domain and a cluster. Answer all ten:
- In two commands, establish who operates the DNS and who operates mail, and say how you know.
- Produce a complete list of names under the domain, and state honestly how complete it is.
- Establish whether the zone is signed, and what that implies for your firewall rules.
- Users report intermittent wrong answers. Name the single piece of evidence that identifies a missed serial bump.
- A name resolves for you and NXDOMAINs for a colleague. Give three possible causes spanning three different modules.
- The apex must point at a load balancer with fast failover. Say what you build and what you refuse to promise.
- Pods take five seconds to reach an external API. Give the arithmetic and the zero-cost fix.
- A signed domain breaks and nobody changed anything. Explain.
- Give the two monitoring alerts that would have caught items 4 and 8 before users did.
- State the one-line rule you would give a junior for reading any dig output.
✅ Model answer — attempt it first, then click
1. dig +short DOMAIN NS and dig +short DOMAIN MX. Nameserver hostnames carry the provider's branding — awsdns means Route 53 — and MX targets name the mail platform, aspmx.l.google.com meaning Google Workspace. Record values, not documentation.
2. Provider API export if you have credentials — the only complete source. Otherwise AXFR against every nameserver, Certificate Transparency, a dictionary sweep, NSEC walking if signed, and mining SPF ip4: ranges and reverse DNS. State the completeness honestly: DNS has no listing operation, so anything short of the API export is a reconstruction. And check for a wildcard first — with one present every result is meaningless.
3. dig DOMAIN DNSKEY and dig DOMAIN DS. If signed, responses roughly triple in size, so ordinary queries will exceed the 1232-byte EDNS buffer and require TCP. TCP/53 must be open in both directions — a rule allowing only UDP/53 turns a signed domain into an intermittent outage where small queries work and large ones hang.
4. Two authoritative servers reporting the SAME serial while returning DIFFERENT records. That single pair is conclusive. The secondary compared serials, saw no change, and correctly did nothing — it is not broken.
5. Module 06 — a local override or search-list difference: /etc/hosts, nsswitch.conf, or a different ndots. Module 03 — a cached negative answer on one resolver, or a lame delegation that only some resolvers hit. Module 08 — split-horizon: the name exists only in a private view, and you are inside it while your colleague is not.
The command that starts the split is getent hosts versus dig, then the same query from the colleague's network position.
6. Build: a Route 53 alias at the apex — a CNAME is illegal there — with health-checked failover routing and a low TTL. Refuse to promise fast failover through DNS. Resolver TTL floors, serve-stale and application caches all outlive your health check. Sub-second recovery must come from anycast or the load balancer; DNS is the slow, eventual layer.
7. ndots:5 plus a three-entry search list means api.example.com — two dots — is relative: three NXDOMAIN queries then the real one. Four queries, eight packets with parallel A/AAAA. A conntrack race drops one, and the client waits the default 5-second timeout. Zero-cost fix: a trailing dot, api.example.com. — absolute, one query, and it is Module 01 A3.
8. The RRSIGs expired. Signatures carry a wall-clock expiration, 30 days by default, and expire whether or not the zone changes. "Nobody changed anything" is the diagnosis, not an alibi — there is no change to review, which is exactly why change management cannot catch it.
9. Serial agreement across all authoritative servers — query each for the SOA and alert if they are not all equal. RRSIG expiry countdown — alert days before, never on validation failure, because by then the domain is already dark.
10. "Read status: and the ANSWER: counter before you read anything else — and if there is no status: line at all, DNS has told you nothing."
The five things most people miss:
- Requirement 2's honesty clause. Handing over a list without saying how complete it is, is the mistake
- Requirement 3's firewall consequence. Everyone says "check for DNSKEY"; the point is what signing does to your network rules
- Requirement 6's refusal. Naming what you cannot promise is the senior half of the answer
- Requirement 8's second sentence — that the absence of a change is the finding
- Requirement 10. Most people give a command; the useful answer is a reading habit
D4 · Official documentation
RFC 5358 is four pages and is the whole of B1. If you read one document from this module, read that.
RFC 4786 for anycast operations — skim §3 and §4, which are the operational sections; the rest is routing theory.
Skim the DoT/DoH/DoQ RFCs only for the transport differences. The protocol details rarely matter operationally; the policy consequences of DoH on port 443 do, and those are not in the RFC.
The offline route, which by now is most of what you need. man dig, man named.conf, man 5 resolv.conf and named-checkzone -D cover the whole track. On a locked-down bastion with no internet, the four-question triage in C1 plus dig and getent will get you through almost any DNS incident.
D5 · Self-assessment
1. How do 13 root server addresses serve the whole internet?
Anycast. The same address is announced by BGP from many locations at once, and each router forwards toward the closest announcement. Over a thousand physical instances answer on those 13 addresses.
It gives low latency without any per-user decision, automatic failure handling — an instance that stops announcing simply disappears — and DDoS traffic divided across every site.
The trade-off is that routing can move you mid-conversation, which is harmless for stateless UDP and a reset for long-lived TCP.
2. Why is DNS a poor load balancer?
It distributes lookups, not requests — one resolver serving a million users caches one answer for all of them. The client picks from an unordered RRset and may reorder or prefer IPv6. DNS cannot see load, only whether a health check passed. And withdrawal is bounded below by TTLs, resolver floors, serve-stale and application caches.
It is useful at the coarse, geographic, slow layer. Real balancing belongs at the load balancer or in the client.
3. Why is a low TTL a liability as well as a cost?
It makes every client depend on your authoritative servers being reachable right now. A long TTL is free resilience: if your nameservers fail, cached answers keep working while you fix them, and serve-stale extends that.
So: long by default, low deliberately and temporarily around a planned change, then back up.
4. Distinguish reflection from amplification.
Reflection — the response goes to a forged source address, so the victim is attacked by your server and the attacker never appears. Amplification — the response is much larger than the query, multiplying the attacker's bandwidth.
Both depend on UDP having no handshake, so there is no proof the source address is genuine.
Defences: recursion no, scoped allow-recursion, RRL, minimal responses, RFC 8482 ANY handling — and BCP 38 source filtering, which is the real fix and is not yours to deploy.
5. Why does RRL truncate rather than drop?
Because a genuine client sees the tc bit and retries over TCP, which requires a handshake — and a spoofed source address cannot complete one.
So legitimate traffic is slowed slightly while reflected traffic is stopped entirely. It is Module 04's truncation mechanism repurposed as a security control.
6. DNSSEC or DoH — which protects what?
DNSSEC authenticates the data from the zone to the validating resolver, and does not hide anything. DoT/DoH/DoQ encrypt the conversation between you and your resolver, and prove nothing about the data.
They are orthogonal and you want both. An encrypted channel to a lying resolver returns lies, privately.
DoH's operational tension: on port 443 it is indistinguishable from web traffic, so a browser with DoH enabled bypasses enterprise split-horizon, filtering and logging invisibly.
7. Which two DNS alerts do most teams lack?
Serial agreement across all authoritative servers, and RRSIG expiry approaching.
They catch the two completely silent failures in this track: a stale secondary answering a share of live traffic with old data, and a signed zone going dark on a date nobody has in a calendar. Both are cheap checks and neither is in a default monitoring template.
8. Why track p99 latency rather than mean for DNS?
Because DNS faults present as latency, not errors. A dead first nameserver costs a full 5-second timeout on every lookup that then succeeds; a Kubernetes conntrack race adds 5 seconds to an occasional query.
Averaged across thousands of fast cache hits, those disappear. The p99 is where they live, and it is what users actually experience.
9. Give the four-question triage, in order, and say why the order matters.
1. Is there a status: line at all? No → nobody answered; this is network, not DNS. 2. What RCODE? REFUSED is policy; SERVFAIL is a failure somewhere. 3. Does +cd fix it? Yes → DNSSEC validation. 4. Do dig and getent agree? No → local: hosts, nsswitch, search list, split-horizon.
The order matters because question 1 is the only one that removes DNS from the investigation entirely, and question 4 covers the causes people never suspect and always find last.
10. What is the last step of a migration, and why is it last?
Decommissioning the old endpoint — and it should be a week after the cutover, not the same day.
Serve-stale and application-level caches keep a tail of clients on the old address well past any TTL you published. Turning it off on the day of the change is how you find out who was still using it: from their outage report.
Nine modules, from "what is a name" to running a signed zone and debugging a cluster. If you can answer the four-question triage in C1 from memory, read a dig header without hesitating, and explain why a change you made an hour ago is still invisible to half the world, you know DNS better than most people who have been operating it for years.
The one habit that outlasts everything else here: read status: first, and remember that no status: line at all means DNS has told you nothing.
📚 Sources for the interview questions
A note on this module's transcripts. Module 09 is a synthesis, and its one hands-on exercise — A1.1's hostname.bind CH TXT probe — is labelled in place as varying by location, because the answer is the point. The environment this was written in sits behind a DNS proxy that intercepts @server queries, so the anycast instance names could not be captured honestly. Run A1.1 from your own machine; the shape will match and the instance name will be yours.
Everything else in this module is drawn from the specifications and vendor documentation linked throughout, all verified to resolve before use.
Specifications verified directly: RFC 1794, RFC 4786, RFC 5358, RFC 5452, RFC 7094, RFC 7858, RFC 8484, RFC 8482, RFC 8618, RFC 9250, RFC 9364, RFC 9715, plus the BIND 9 ARM and the Kubernetes DNS debugging guide.
Question selection cross-referenced against publicly published 2026 DNS, network-security and DevOps interview question sets:
- Top 25 DNS Interview Questions and Answers for 2026 — nitizsharma.com — DNS load balancing in detail, DNS query logging, what causes resolution failure
- Top 30 Most Common DNS Interview Questions — Verve AI — Anycast and GeoDNS, common DNS security risks and best practices, troubleshooting scenarios
- Top 100 Network Security Interview Questions for Network Engineers (2026) — The Network DNA
- 50 Must-Prepare Networking Interview Questions for DevOps Engineers
- How to Pass DevOps Interviews in 2026 (Real Engineer Guide)
Answers were rewritten and deepened rather than reproduced. Published sets list the load-balancing techniques; almost none say why DNS is a poor load balancer, that RRL truncates rather than drops, or that DNSSEC and DoH solve different problems. Those distinctions are what an interviewer who has operated DNS at scale is listening for.