See It Flow
Interactive guide · 4 chapters · ~12 min read

DNS Interview & Revision

Everything you need for a final pass before an interview — useful practice prompts, condensed revision notes, a self-check quiz, and a cheat sheet of commands and defaults.

Mangesh MandlikLast updated:
01 · Practice

Interview Questions

Questions ordered from fundamentals toward production depth so you can practice building an explanation step by step.

What happens when you type a URL into a browser, focusing on DNS?

Walk the full chain: browser cache → OS cache → recursive resolver → (if not cached) root → TLD → authoritative nameserver → IP returned and cached at every layer on the way back.

What is the difference between a recursive resolver and an authoritative nameserver?

The resolver does the work of walking the hierarchy on the client's behalf and caches results; the authoritative nameserver is the actual source of truth for a domain's records and does no work on anyone else's behalf.

What is a TTL and why does it matter?

The number of seconds a cache is normally allowed to reuse a DNS answer before refreshing it. It is the main lever controlling the trade-off between resolver load/latency (favor higher TTLs) and change-propagation speed (favor lower TTLs), even though different cache layers do not all refresh at exactly the same instant.

Why does DNS use UDP, and when does it use TCP instead?

UDP by default for the fast common case; TCP for zone transfers between nameservers and when a UDP response is truncated or otherwise too large to return comfortably in one datagram (which becomes more common with large or DNSSEC-heavy answers).

How does DNS help load-balance traffic?

Round robin across multiple A records for one name, optionally combined with GeoDNS/latency-based routing to send users to their nearest healthy region — layered underneath (not replacing) an in-path load balancer.

How does DNS-based failover work, and what are its limits?

A DNS provider health-checks each candidate endpoint and stops returning unhealthy ones in new answers after detection. The limits are cache lifetime and detection delay: some clients and resolvers keep using older answers until they refresh, so failover is not instantaneous.

What is a PTR record and where is it used?

The record type used for reverse DNS — IP → hostname — commonly checked by mail servers as a basic anti-spam signal (forward-confirmed reverse DNS).

What problem does DNSSEC solve?

It adds cryptographic signatures so a resolver can verify a response is authentic and unmodified, closing the cache-poisoning gap in plain DNS — but it does not add confidentiality.

02 · Quick recall

Revision Notes

Condensed, scannable notes for a last-minute refresh.

Key takeaways
  • Resolution order: browser cache → OS cache → recursive resolver (cache) → root → TLD → authoritative nameserver.
  • Recursive = client↔resolver relationship. Iterative = resolver↔hierarchy relationship.
  • A/AAAA = hostname → IP. CNAME = alias. MX = mail. TXT = freeform (SPF/DKIM). NS = authoritative servers. PTR = reverse lookup.
  • TTL sets the intended cache lifetime across layers — lower it before planned migrations, days in advance, but expect refresh timing to vary a bit by client and resolver.
  • UDP by default; TCP for zone transfers and for UDP responses that are truncated or too large to return cleanly in one datagram.
  • DNS round robin ≠ a full load balancer — no real-time health awareness beyond periodic external checks.
  • DNS-based failover is bounded by health-check detection time plus however long older answers remain cached by clients and resolvers.
  • DNSSEC = authenticity/integrity only, not encryption — use DoH/DoT for query privacy.
  • Reverse DNS uses in-addr.arpa (IPv4) / ip6.arpa (IPv6) and PTR records; must be configured by whoever owns the IP block.
03 · Self-check

Quiz

Cover the answer and try each question before revealing it.

Q1. A resolver asks the root server for help and gets back a referral, not a final IP. Is this query recursive or iterative?

Answer: Iterative — the root server tells the resolver who to ask next rather than resolving on its behalf.

Q2. Which record type would you use to point `blog.example.com` at `example.com`'s existing servers without duplicating IPs?

Answer: A CNAME record.

Q3. Your team just migrated to a new hosting provider and updated the A record, but some users still hit the old server for hours. Why?

Answer: Their resolvers cached the old record with a long TTL that hadn't been lowered ahead of the migration — the change was instant at the authoritative server, but stale caches elsewhere hadn't expired yet.

Q4. Why might a DNS response get retried over TCP instead of UDP?

Answer: The UDP response was too large and got truncated (TC flag set) — commonly with DNSSEC-signed zones or records with many entries.

Q5. What does DNSSEC protect against, specifically?

Answer: Cache poisoning / response tampering — it verifies authenticity and integrity of responses, not confidentiality.

04 · Reference

Cheat Sheet

Commands and defaults worth having memorized.

bashTrace the full resolution path
dig +trace example.com
bashQuery a specific record type from a specific resolver
dig MX example.com @8.8.8.8
bashReverse lookup (IP → hostname)
dig -x 93.184.216.34
bashBypass caches — ask the authoritative server directly
dig example.com @ns1.example.com
textRecord type quick reference
A       hostname -> IPv4
AAAA    hostname -> IPv6
CNAME   alias -> another hostname
MX      priority + mail server
TXT     freeform text (SPF/DKIM/verification)
NS      authoritative nameservers
PTR     IP -> hostname (reverse)
textDefault port & transport
Port: 53
Default transport: UDP
TCP use cases: zone transfers; truncated or oversized UDP responses (more common with large/DNSSEC-heavy answers)