DNS Interview Questions and Answers for 2026

Answer: A globally distributed database that maps names to records, mostly IP addresses, so software can target services without hardcoding addresses. The mechanism: a hierarchy of zones delegated from the root, queried through resolvers that cache answers for a TTL. The consequence: nothing is centralized except the delegation chain, so outages and debugging are always local questions about a specific hop. It is the opening definition of the whole topic, so deliver it in one breath and stop.

Answer: Because IPs are allocation units, not service addresses: they change with failover, migrations, autoscaling, and CDN steering. DNS decouples the name from the location, adds a policy layer, multiple answers, weighted and geographic routing, health-based failover, and lets you move a service without touching a single client. Saying that DNS is indirection with policy attached is the sentence that separates strong candidates in DNS interview questions from people who memorized record types.

Answer: The record that maps a hostname to an IPv4 address, like www.example.com to 203.0.113.10. One detail worth adding: a name can hold multiple A records in one RRset, and answering with all of them is how simple DNS round-robin spreads load. Also know the IPv6 equivalent is AAAA, not “A6”, a trap that appears in written rounds more often than you would expect.

Answer: The IPv6 sibling of the A record: same job, 128-bit addresses. Practical consequences interviewers like: dual-stacked names carry both A and AAAA RRsets, clients may try either, and a published AAAA with broken IPv6 routing causes connection timeouts rather than clean fallback, which is why Happy Eyeballs exists. Volunteering that publishing AAAA is an operational commitment, not a copy-paste, already passes the intent of this entry in DNS interview questions.

Answer: An alias: it points one name at another name, and the client resolves that target to finish the job. The rule that matters: a CNAME cannot coexist with any other record on the same owner name, which is why it is banned at zone apexes where SOA and NS must live. CNAME versus A is the most common opener in beginner DNS interview questions because it tests whether you know records are typed and mutually exclusive per name.

Answer: The record naming where mail for a domain is delivered: a priority integer plus a hostname, like 10 mail.example.com. Lower numbers are tried first; equal numbers spread load. Two details that earn credit: MX values must be hostnames with their own address records, never bare IPs, and delivery falls back to the domain’s A record only when no MX exists at all. Mail-routing follow-ups are standard follow-ups here, so know the fallback rule cold.

Answer: A record holding arbitrary text, which the industry repurposed for policy: SPF sender authorization, DKIM public keys, DMARC policies, and ownership verification for certificate authorities and cloud providers. Mechanically it is a character string, up to 255 bytes per quoted chunk, with longer values split into chunks receivers concatenate. Because so much authentication lives in TXT, most deliverability scenarios in DNS interview questions begin with dig TXT on some name.

Answer: The record saying which nameservers are authoritative for a zone. It exists in two places: in the parent zone as the delegation pointer, and in the child zone as the authoritative list. When the two disagree, you get outages that hit only part of the internet, because different resolvers trust different sides. NS records sit under nearly every intermediate and scenario topic in this bank, so be ready to explain both placements from memory.

Answer: The reverse of an A record: given an IP, it returns a name, looked up in reverse zones under in-addr.arpa for IPv4 and ip6.arpa for IPv6. The uses to name: mail receivers check that a sending IP’s PTR exists and matches forward resolution, and log pipelines resolve IPs to hostnames for readability. PTR is controlled by whoever owns the network’s address block, not the domain owner, a distinction that regularly trips up candidates in DNS interview questions.

Answer: The record every zone starts with, naming the primary nameserver, an admin mailbox, and five timers: serial, refresh, retry, expire, and minimum. It answers who is in charge of this zone and how should copies behave. At this level, say that the serial changes on every edit and drives replication to secondaries, and that the minimum field sets how long negative answers are cached. The timers in depth are a favorite follow-up in DNS interview questions.

Answer: A record that locates a service, not just a host: it encodes priority, weight, port, and target under names like _sip._tcp.example.com, so applications such as LDAP or SIP discover endpoints without hardcoded ports. The detail worth adding: HTTP never adopted SRV; the web still uses plain A and AAAA plus the newer HTTPS record type, so why didn’t the web use SRV is a common curveball in DNS interview questions.

Answer: A record stating which certificate authorities may issue certificates for the domain, with issue, issuewild, and iodef tags for reporting violations, and CAs are required to check it before issuing. The interview angle: CAA does not affect resolution and encrypts nothing; it constrains issuance. That makes it a clean test of whether candidates confuse DNS policy records with resolution records, a mix-up interviewers hunt for in DNS interview questions.

Answer: The middleman of resolution: a server, run by your ISP, your cloud provider, or a public service like 1.1.1.1 or 8.8.8.8, that takes a complete question, does all the walking from root to TLD to authoritative, caches the answer for its TTL, and replies. Your laptop only ever talks to it. Explaining that recursion happens on the resolver, not the client, is exactly the precision beginner DNS interview questions are checking for.

Answer: The server holding a zone’s actual records, answering for them with final say from its own data rather than a cache. Recursive servers end up there after following referrals. State the contrast cleanly: recursive servers answer from cache or go find the answer; authoritative servers answer from the zone. Recursive versus authoritative is the single most repeated pairing in DNS interview questions, so have a crisp two-sentence version ready.

Answer: The top of the hierarchy: the unnamed dot zone that delegates every TLD. Thirteen named root server identities, a through m, serve it, anycast-replicated onto well over a thousand instances worldwide. What interviewers want: the root does not know your domain; it only refers you to the right TLD, and the 13 names are logical identities, not 13 machines. That referral-only job is the entire point of root questions in DNS interview questions.

Answer: A top-level domain: com, org, country codes, and newer generic entries, each run by a registry operating the nameservers every lookup passes through. The registry delegates second-level domains to registrants via NS records. Worth one sentence: registries, registrars, and DNS hosting are three distinct roles, and conflating them is a classic stumble at this level because almost every real task touches all three.

Answer: Any name below another name in the tree: api.example.com is a subdomain of example.com. The precision to add: a subdomain only becomes a separate zone if someone delegates it with NS records at the parent; until then it is just names inside the parent zone. That subdomain-versus-delegated-subzone distinction is a quiet favorite in DNS interview questions, because it decides where you edit records when something breaks.

Answer: A fully qualified domain name: the complete path from hostname to root, written with a trailing dot, like www.example.com., making it absolute rather than relative to a search list. The operational reason it matters: software and zone files that omit the dot can accidentally build names like www.example.com.example.com, a bug that shows up in DNS interview questions as my record contains my own domain twice, why.

Answer: The domain is the name; the zone is the slice of namespace one party administers, starting at a zone cut and containing every name below it that has not been delegated away. One domain can be split into many zones, and one zone can hold many subdomains. Zone versus domain decides where records live, and it anchors half the delegation scenarios in DNS interview questions.

Answer: The text representation of a zone: SOA and NS at the top, then A, AAAA, CNAME, MX, and TXT records line by line, with shortcuts like @ for the zone origin and blank names inheriting the previous record’s owner. Even cloud DNS consoles are this model underneath, and import and export use the format. Reading one fluently is baseline expectations territory in DNS interview questions for any ops role.

Answer: Shorthand for the zone origin, so @ IN A 203.0.113.10 creates the apex record for example.com itself. The trap attached to it: a name written without a trailing dot is relative to that origin, so mx.example.com without the dot becomes mx.example.com.example.com. That single missing dot has caused more real outages than most record types, which is why it keeps resurfacing in DNS interview questions year after year.

Answer: A record with an asterisk owner, like *.example.com, that answers any name with no exact record of its own. It is how tenant-per-subdomain routing works cheaply and how marketing teams self-serve campaign pages. Know the boundary: once a specific record exists at a name, the wildcard stops covering names beneath that name, a subtlety that intermediate rounds turn into full troubleshooting scenarios.

Answer: An A or AAAA record the parent zone serves alongside its delegation NS records, required when a nameserver’s own name lives inside the zone it serves, like ns1.example.com inside example.com. Without glue, resolving example.com would require resolving ns1.example.com first, a chicken-and-egg loop. Saying glue breaks the circular dependency is the phrase that closes this entry in beginner DNS interview questions.

Answer: The primary holds the editable master copy of the zone; secondaries pull read-only copies via zone transfers, and both answer queries identically. Resolvers and clients see no difference in authority. The point to land: this is replication for redundancy, not a hierarchy of truth, and every zone needs at least two nameservers on separate networks because a single one is a single point of failure. Redundancy reasoning is common in DNS interview questions at this level.

Answer: The registrar is where you buy and renew the domain and where the delegation, the nameserver list, is published to the registry. The DNS host, which may be the same company or not, is where the zone’s records live. Change the nameservers and you point everything at a different zone; change a record and you edit inside the current one. That split is the operational heart of migration questions in DNS interview questions.

Answer: WHOIS is the registration directory: owner, expiry date, registrar of record. DNS answers queries about names and addresses; WHOIS answers questions about the registration itself. The ops reason it matters: expiry and stale registrant contacts break resolution in ways that look like DNS failures but never appear in any dig output, which is why WHOIS is a standard early step in any mystery-outage triage.

Answer: The number of seconds an answer may be cached before it must be refreshed: 300 means five minutes. Every RRset carries one, resolvers count it down and re-query at zero, and the value dig shows is remaining life, not the configured number. TTL is the knob that controls how fast changes reach the world, and nearly every migration scenario in DNS interview questions is at bottom a TTL story.

Answer: At many layers: the browser may cache, the operating system’s stub resolver or systemd-resolved caches, the home router often does, and the recursive resolver definitely does. Each layer holds answers independently for the TTL, which is why flushing one layer rarely fixes anything alone. Naming at least three layers is the expected answer, because cache-flush questions are really questions about the layers.

Answer: Three things: a name, a type, and a class, with IN for internet as the practical default. The type is the gotcha: www.example.com A and www.example.com MX are different questions with different answers and separate cache entries. Interviewers use this to test whether you understand that resolving a domain is always resolving a name for a specific type, the mental model behind most follow-ups in DNS interview questions.

Answer: Both, on port 53. Queries and normal answers ride UDP because they are small and one-shot. TCP takes over when a response is truncated, for zone transfers, and when DNSSEC payloads outgrow the path. The sentence to add: the client retries over TCP after receiving the TC flag, so a firewall blocking TCP 53 fails only large answers, a classic selective-failure trap in DNS interview questions.

Answer: The standard DNS debugging tool: dig example.com sends an A query to your configured resolver and prints the question, the answer with per-record TTLs, and the server that replied. Starting flags: +short for the bare answer, @8.8.8.8 to query a specific server, +trace to walk the whole delegation chain. Comfort in dig is assumed in nearly every technical round of DNS interview questions, so make it muscle memory.

Answer: Lighter lookups: host gives compact one-line answers and handles reverse lookups with host 203.0.113.10, while nslookup is interactive and ships on Windows, making it the fallback on locked-down machines. The honest framing interviewers like: dig for depth, host for speed, nslookup for Windows boxes. Knowing which tool exists where is itself part of how these questions test real-world experience rather than theory.

Answer: It is the record class: internet. Three classes were defined, IN, CHAOS, and Hesiod, and IN won so completely that dig and most servers default to it and often hide it; CHAOS survives in the wild for queries like version.bind. It is a small vocabulary check that appears in written DNS interview questions to separate people who have read real zone files from people who have only clicked consoles.

Answer: Publishing several A records for one name so the server rotates their order, spreading clients roughly evenly across addresses. It is free and stateless, but it is not health-aware: if one address dies, a slice of users keeps hitting it until TTLs let answers change. That limitation is exactly why dynamic routing exists, and interviewers often use this pair to walk you from static to health-checked answers.

Answer: Redundancy: resolution for the entire zone dies with one server, and DNS is the dependency of everything else, so it gets no single points of failure. Best practice is at least two nameservers on separate networks, and registries require a minimum to delegate at all. Answering because one is an outage waiting to happen, ideally with a real nameserver-failure story, is the strong version of this entry in DNS interview questions.

Answer: Per layer: Windows uses ipconfig /flushdns, macOS dscacheutil -flushcache plus killall -HUP mDNSResponder, Linux with systemd-resolved uses resolvectl flush-caches, and a BIND server flushes with rndc flush; browsers manage their own. The answer interviewers want includes and which layer was actually holding the stale answer, because flushing the wrong layer is the recurring joke inside DNS interview questions about stale records.

Answer: Yes: glibc’s resolver follows /etc/nsswitch.conf, typically hosts: files dns, so /etc/hosts is consulted before any nameserver. That ordering makes hosts files the tool for pinning a name during a migration and the culprit when one box resolves a name differently than everyone else. Checklist debugging in DNS interview questions often starts with check for a hosts entry for exactly this reason.

Answer: Someone answers your queries with records they chose: by compromising a registrar login and rewriting delegation, by malware editing the local hosts file or resolver settings, or by an interceptor on the network path. Consequences range from ad injection to credential theft, and defenses include registrar lock, DNSSEC for data integrity, and encrypted transports. Keeping those three attack surfaces separate is what beginner DNS interview questions on this topic are really testing.

Answer: An application asks the stub resolver for www.example.com A; the stub forwards to its configured recursive resolver with the recursion-desired bit set. The recursive resolver checks cache; on a miss it asks a root server, which refers it to the com servers; com refers it to example.com’s nameservers, passing glue addresses when needed; the authoritative server returns the A RRset with its TTL. The resolver caches the answer, replies to the client, and serves every repeat ask from memory until the TTL runs out. Narrating each hop and where caching attaches is the canonical performance in DNS interview questions.

Answer: Recursive means get me the final answer, do whatever walking it takes; iterative means give me your best referral and I will continue myself. Clients send recursive queries, RD bit set, to their resolver; resolvers send iterative queries to root, TLD, and authoritative servers, which may answer with referrals instead of data. Servers advertise capability with the RA bit. The bits sit in every dig header, which is why this distinction is graded hard in mechanism-tier DNS interview questions.

Answer: Question: name, type, class. Answer: records that directly respond. Authority: records pointing at the authoritative source, NS records in referrals, an SOA in negative answers. Additional: helpful extras, classically glue addresses for referred nameservers. Reading the sections is a debugging skill: an empty answer with an authority SOA is a cacheable negative answer, not an error. Interviewers watch for candidates who misread authority-section data as a failure, one of the quiet classics in DNS interview questions.

Answer: A referral is a non-answer that says ask these servers instead: an authority section carrying NS records for a child zone, ideally with glue addresses in the additional section. The resolver notes the delegation, re-sends its query to one of the referred servers, and repeats until an authoritative answer or a definitive negative arrives. Stale or misissued referrals are how lookups die silently halfway, and explaining referral-following is one of the standard depth probes in DNS interview questions.

Answer: Secondaries poll the primary’s SOA at the refresh interval; if the poll fails they retry at the retry interval; if they cannot reach the primary for the expire interval they stop answering for the zone entirely, the fail-safe. NOTIFY messages short-circuit the polling: each edit pushes a notice so secondaries transfer immediately. Knowing that expiry makes a secondary go silent rather than serve stale forever is the detail that separates prepared candidates in DNS interview questions.

Answer: The serial is the zone’s version number: secondaries compare it and only transfer when the primary’s is greater, using serial number arithmetic. AXFR pulls the entire zone over TCP; IXFR requests changes since a known serial and receives deltas, which matters on huge zones. The classic trap: editing records without bumping the serial, so secondaries never learn, then blaming the network. Serial discipline is one of the oldest war stories in DNS interview questions.

Answer: A primary nameserver deliberately left out of the public NS records: it feeds secondaries via transfers but answers no queries from the internet. Benefits: the editable master sits behind a firewall with a tiny attack surface, and public nameserver changes never touch it. The tradeoff: every update depends on the transfer path staying healthy, so NOTIFY reachability and the expire timer need monitoring. Hidden primaries come up in design-flavored rounds for senior ops roles.

Answer: NXDOMAIN and NODATA answers are cached too, so a nonexistent name is not re-queried on every request. The TTL comes from the SOA record attached to the negative response: resolvers use its minimum field, capped by their own maximum, historically recommended at three hours. The operational sting: fix a delegation typo and correct resolvers may keep serving the cached NXDOMAIN until the negative TTL lapses. That sting is why negative caching is a fixture of DNS interview questions.

Answer: NOERROR with records is success; NOERROR with no records is NODATA, a name that exists without the requested type. NXDOMAIN is a confident declaration that the name does not exist, and it is cacheable. SERVFAIL means the resolver tried and failed: dead authoritative servers, lame delegation, or a DNSSEC validation failure upstream. REFUSED means a server responded only to decline, usually policy: recursion disabled or an ACL. Reading the code before changing anything is the reflex this entry in DNS interview questions builds.

Answer: Extension Mechanisms for DNS, version 0: a pseudo-record in the additional section that lets clients advertise a larger UDP payload, typically 1232 to 4096 bytes, and carry options like the DNSSEC DO bit and EDNS Client Subnet. Original messages capped at 512 bytes, which DNSSEC signatures blow past immediately. Middleboxes that mangle EDNS cause the classic intermittent large-answer failures, and debugging them appears in senior rounds about flaky TXT-heavy lookups.

Answer: Three triggers: the TC bit on a truncated UDP response, which sends the client back over TCP; inherently large operations like AXFR and IXFR zone transfers; and DNSSEC-heavy responses that exceed even negotiated EDNS sizes. RFC 7766 made TCP a first-class transport with connection reuse and backoff rules. Operational consequence: firewalls must pass TCP 53 or big answers fail selectively, the exact pattern interviewers describe in DNS interview questions as small lookups work, TXT lookups time out.

Answer: Every RRset is signed into an RRSIG by a zone key published in DNSKEY; the validator fetches the keys, checks that the parent’s DS record fingerprints the child’s key, and climbs the same chain to the root’s trust anchor. A validating resolver sets the AD bit on success and returns SERVFAIL on a broken chain: missing signature, expired validity, or DS mismatch. DNSSEC proves integrity, not confidentiality, and it is the standard answer to how do you beat cache poisoning in DNS interview questions.

Answer: Under DNSSEC even NXDOMAIN needs a signature. NSEC chains each existing name to its alphabetical neighbor, so a validator can confirm the requested name falls between two real ones; the cost is that anyone can walk the entire zone by following the chain. NSEC3 hashes the names first, breaking casual walking at the price of extra CPU on both sides. The NSEC versus NSEC3 tradeoff is a tidy depth signal in senior DNS interview questions.

Answer: An attacker races a resolver’s legitimate query with forged responses, hoping a fake record lands in cache first; the Kaminsky attack industrialized this by flooding forged authorities for random subdomains. Defenses: unpredictable 16-bit query IDs plus randomized source ports, 0x20 question-case randomization, strict bailiwick checks that drop answers for other zones, and DNSSEC signatures that forgeries cannot satisfy. Naming at least two defenses is the bar for this classic in DNS interview questions.

Answer: One IP announced via BGP from many data centers, so routing delivers each query to the nearest healthy site and withdraws dead ones automatically. Root servers, TLDs, major recursive resolvers, and managed DNS platforms all run anycast for latency and DDoS absorption. The caveat worth adding: routing health is not service health, so a sick anycast node can keep attracting traffic until withdrawal, which is why anycast probing shows up in questions about global platforms.

Answer: It ships with a root hints file listing the 13 root nameserver names and addresses; modern resolvers instead prime, querying for the root’s NS RRset to learn current addresses and TTLs, then refreshing them over time. From there the normal iterative walk begins. The detail interviewers like: root server addresses change rarely but do change, which is why hints files ship with the resolver package and get updated by maintainers. Bootstrap questions appear in interviews for network-leaning roles.

Answer: Two coordinated pieces: NS records for the child placed in the parent zone at the zone cut, and the child zone carrying its own SOA plus a matching NS list at its apex. Add glue records when the child nameservers live inside the child’s own names. The delegation is consistent only while both sides agree; half-migrated delegations produce resolvers that follow different valid-looking paths, which is the root cause behind many intermittent scenarios in DNS interview questions.

Answer: A delegation whose NS records point at servers that do not answer authoritatively for the zone: an unconfigured secondary, a wrong server, or a firewall in front of one. Resolvers burn timeouts on lame servers and may fail lookups even though other nameservers are healthy, producing works for most users symptoms. Detect it per server: dig @each-nameserver the-zone SOA and compare; a timeout, REFUSED, or missing AA bit marks the lame one.

Answer: It tracks performance: BIND-style resolvers keep a smoothed round-trip time per nameserver, prefer the fastest, penalize timeouts, and periodically re-probe the rest so a recovered server rejoins rotation. Practical effect: you cannot predict which nameserver served any given query, and one slow or lame server degrades only the slice of queries that reach it, which explains the intermittent patterns interviewers love to ask about. Name SRTT or response-time tracking to pass this one.

Answer: By question tuple: name, type, and class, storing whole RRsets with one countdown TTL taken from the answer. TTLs decay to zero and are then refreshed or evicted; some resolvers add serve-stale, answering expired data during upstream outages. The subtlety worth naming: answers synthesized through a CNAME cache each link separately with its own TTL, so mixed-TTL chains age unevenly, a sharp edge that surfaces in questions about why half a name’s records went stale.

Answer: Authoritative Answer: the responding server claims the zone itself, not a cache or a referral. In dig output it appears in the flags line, like flags: qr aa rd; a direct query to a nameserver hosting the zone sets aa, while the same query through your recursive resolver does not. It is the quickest way to confirm you are truly talking to the source of truth, which is why AA-reading appears in hands-on DNS interview questions.

Answer: The apex must carry SOA and NS records, and the protocol forbids co-locating a CNAME with any other data on the same owner name, so a CNAME at the apex would break the zone’s own existence requirements. Consequence: example.com itself cannot be an alias, so apex traffic needs real A and AAAA records or provider-side flattening. This rule and its workaround are among the most common intermediate DNS interview questions because every CDN onboarding collides with it.

Answer: The provider resolves the target’s addresses itself, at query time or on a schedule, and serves them as ordinary A and AAAA records at the apex, so resolvers see synthetic address records where the zone data says CNAME. Route 53’s ALIAS does it natively for AWS targets at no query cost; generic ANAME implementations resolve periodically. Know the tradeoff: flattened answers follow the target’s TTL, and this provider-specific behavior is a recurring trap in cloud-flavored DNS interview questions.

Answer: CNAME redirects one exact name; DNAME redirects an entire subtree: a query for anything under old.example.com is rewritten as a CNAME into the target suffix. Uses: domain renames and sharing reverse zones across providers. Caveats: the DNAME owner itself is not redirected, delegation points inside the subtree break the substitution, and resolver support was historically uneven. DNAME is a sharpness probe in senior rounds rather than a daily tool.

Answer: Each link is another lookup: www.example.com to cdn.example.net to edge.provider.com means up to three sequential round trips before any address, each with its own TTL and failure mode. Latency accumulates on cold caches, and one dead link breaks resolution entirely even though the final target is healthy. Keeping chains to one hop, or flattening them, is the advice interviewers expect when the topic of slow first loads comes up.

Answer: A wildcard answers a query only when the exact name does not exist and its closest encloser, the nearest existing ancestor, carries the wildcard. Two consequences people miss: adding any record at a name, say a single A for mail.example.com, stops *.example.com from covering names beneath mail.example.com, and empty non-terminals, names that exist only as prefixes of deeper names, also block matching. Wildcard boundary bugs are a reliable way DNS interview questions test whether you have run real zones.

Answer: Upside: changes reach users within minutes and failover routing works inside the TTL window. Costs: every resolver re-queries far more often, so authoritative query volume, cache-miss latency, and vendor billing all rise, and a DNS provider outage stops being survivable from cache. The common compromise: 300 seconds normally, dropped to 60 well before a planned cutover, raised again after. That kind of reasoning is what intermediate DNS interview questions listen for on TTL.

Answer: Authoritative servers may rotate RRset order per query; resolvers generally cache what they received and return it, and client stacks differ: most applications try the first address, some randomize, dual-stack ones follow Happy Eyeballs. So round-robin distribution is approximate at best and health-blind always. The precise phrasing that earns the point: distribution depends on the whole chain from your server to the client stack, not just your server.

Answer: Three structural gaps: answers are cached for the TTL, so changes lag traffic; distribution happens per lookup, not per connection, and ignores real server load; and there is no health model, so a dead address keeps being served until records change. DNS excels as the first tier, steering regions toward regional load balancers that make per-request decisions. Framing DNS as tier one of two is the mature answer in architecture-adjacent DNS interview questions.

Answer: The DNS platform probes an endpoint, a URL or TCP port, on an interval from multiple vantage points and flips answers between primary and secondary pools based on check state: Route 53 failover records, NS1 and Cloudflare equivalents. Two honest caveats: detection latency is the check interval plus the answer TTL, and the check must probe what users actually experience, not a static page that stays green while the app is down. Those caveats are the substance of failover questions in DNS interview questions.

Answer: The authoritative server picks answers based on the resolver’s source IP by default, which is why a corporate resolver in one country breaks geo steering for users everywhere. EDNS Client Subnet lets resolvers forward a truncated client prefix, so answers reflect users rather than resolvers, at a privacy cost that makes ECS opt-in per resolver. Explaining the resolver-IP failure mode and its fix is the point of geo-routing questions in DNS interview questions.

Answer: One name resolves differently inside and outside the network: internal users get private addresses for app.internal.example.com while outsiders get public answers. Implementations: BIND views matching client subnets, appliance products, or cloud pairs like Route 53 private hosted zones versus public ones, bridged with conditional forwarding. The operational risk to name out loud: internal and external copies drift, so changes must be applied and tested on both sides, the discipline split-horizon questions in DNS interview questions probe.

Answer: A forwarder hands a resolver’s misses to another resolver instead of walking from root: common in offices that want a corporate or ISP upstream with local cache on top. A conditional forwarder is scoped: all queries for partner.com go to the partner’s nameservers, everything else recurses normally. They are the plumbing behind mergers, Active Directory domains, and private-link resolvers, and mis-scoped forwarders are a recurring villain in DNS interview questions about resolves on one subnet only.

Answer: DNS over TLS wraps queries in TLS on port 853; DNS over HTTPS embeds them in ordinary HTTPS traffic on 443. Both encrypt the path and defeat on-network tampering, and both complicate enterprise life: filtering, logging, and split-horizon answers depend on clients using the corporate resolver, and browsers enabling DoH quietly bypass it. DoH versus DoT tradeoffs now appear in modern DNS interview questions for security-aware roles, so have a position, not just a definition.

Answer: Clients query structured names instead of a registry: SRV records for host and port, TXT for metadata, and systems like Consul or Kubernetes headless Services returning the A records of every matching instance so callers balance themselves. The promise: zero extra infrastructure, since DNS is everywhere. The limit: clients cache for the TTL, so instance churn demands very low TTLs and callers that tolerate stale members. This pattern is a guaranteed topic in cloud-native DNS interview questions.

Answer: Kubernetes sets ndots:5 in pod resolv.conf, so any name with fewer than five dots is tried against every search domain first: external.example.com generates queries like external.example.com.default.svc.cluster.local before the bare external name, multiplying latency and upstream load. Fixes: absolute names with a trailing dot for external calls, lower ndots via dnsConfig, or NodeLocal DNSCache. This one is among the most practical recent additions to DNS interview questions for platform teams.

Answer: Happy Eyeballs, RFC 8305, races IPv6 and IPv4 connection attempts with a small head start for IPv6, so a dead IPv6 path costs milliseconds instead of seconds. It only helps clients that implement it: older stacks, appliances, and embedded devices still serialize, hang on the AAAA, then fall back. Publishing AAAA records therefore requires real IPv6 end to end, and it works on my laptop is not validation, a caveat that earns credit in DNS interview questions on dual-stack.

Answer: Reverse zones live under in-addr.arpa, one zone per octet boundary: your ISP or RIR owns 113.0.203.in-addr.arpa and either hosts the PTR records for you or delegates your slice to your servers. For prefixes longer than a /24, normal delegation cannot align to octets, so RFC 2317 uses CNAMEs per address into a subdomain you control. Forward-confirmed reverse DNS for mail senders is the payoff story interviewers expect alongside reverse delegation questions.

Answer: An ongoing key lifecycle, not a checkbox: sign zones with KSK and ZSK or a combined key, publish DNSKEYs, keep the parent’s DS record in sync, and roll keys on schedule without breaking validators, since a DS mismatch or an expired signature turns into domain-wide SERVFAIL. Teams stage rollovers with double-signing or pre-publication and monitor signature expiry. Ops crews learn this the hard way, which is why rollover stories dominate senior DNS interview questions on DNSSEC.

Answer: Nothing propagates: your authoritative servers change immediately, and every recursive resolver simply serves its cached copy until the TTL expires on its own clock. There is no push, no fan-out, no global 48-hour timer; propagation delay is really the tail of independently expiring caches, bounded by the TTL configured before the change. Debunking the myth with that framing is exactly what intermediate DNS interview questions want when the word propagation appears.

Answer: The application is alive, so the break is between name and connection. Order: dig the name and see what your resolver returns; compare with dig @1.1.1.1 and a dig +trace to check the authoritative path; then confirm the returned IP is the one your curl reached. Common findings: a stale record pointing at a decommissioned host, a nameserver outage making some resolvers fail while others serve cache, or an expired domain nobody noticed. Stating name resolves, address connects, so I bisect the name path out loud is the winning move in scenario DNS interview questions like this one.

Answer: Caches, in layers: every recursive resolver that answered inside the old TTL is still within its countdown, and browser and OS caches on user machines add their own windows on top. Verify by running dig +short against several public resolvers and watching old and new answers coexist. The fix is patience bounded by the old TTL, plus comms for the tail; the prevention is lowering the TTL days before a cutover and raising it after. Migration TTL pain is the most replayed story in DNS interview questions, so tell it fluently and cite the layers.

Answer: NXDOMAIN is a definite does not exist, so the question is which layer confidently believes that. Compare dig against your resolver, against 1.1.1.1, and directly against an authoritative nameserver. If only your resolver says NXDOMAIN, suspect its negative cache: someone fixed a typo and this resolver is still serving the cached failure for the negative TTL, or it forwards to a broken upstream. If the authoritative server also denies the zone, check delegation at the parent and whether the zone still loads. NXDOMAIN’s confidence is what makes it diagnostic.

Answer: SERVFAIL means somebody tried and could not produce a trustworthy answer: the authoritative chain timed out, delegation is lame, or DNSSEC validation rejected the data. Bisect outward: run dig +dnssec and dig +cd against your resolver, where success with +cd points at validation as the killer; query each authoritative nameserver directly to find the dead or refusing one; run dig +trace to find the hop where referrals stop. SERVFAIL versus NXDOMAIN is the fork every debugging path starts from, which is why it anchors so many DNS interview questions.

Answer: +trace replays the resolver’s own walk from the root and prints each hop. Read it as a funnel: the root referral appears, then the TLD referral, then the authoritative answer, and the last successful line marks the broken hop. Root answering but no TLD referral points at registry delegation; authoritative servers timing out points at the hosting side; a trace that never starts points at your own resolver or network path. Walking the trace aloud and naming each hop’s job is exactly how interviewers score this entry in DNS interview questions.

Answer: Read the bounce first: the receiver claims your sending IP is not authorized for the envelope domain. Then dig txt your-domain and parse the SPF: which mechanisms authorize your senders, is the sending platform’s include present, and does the record end in a deliberate all policy. Then count DNS lookups, because SPF allows ten, and over-limit records evaluate to a permanent error at many receivers. Fix the record, verify from outside with dig, and retest. Order before action is what this tier grades.

Answer: Treat it as an alignment problem across three records. Check SPF with dig txt and add the new provider’s include while removing the dead one. Fetch the new provider’s DKIM selector and confirm selector._domainkey.example.com exists and matches what they sign with. Then read _dmarc: the policy plus alignment, since SPF or DKIM must pass for the visible From domain, not just any domain in the message. Send a test through a checking tool, read Authentication-Results headers on a delivered message, and only then touch the DMARC policy. Mail auth is the most scenario-heavy corner of DNS interview questions.

Answer: Sequence: dig mx customer-domain to confirm a valid MX hostname exists and resolves; then test reachability of that host on port 25, because many networks and clouds block outbound 25 and the symptom is timeouts to everyone, not just this domain; then read your MTA logs for greylisting or TLS handshake failures, which appear as retries with delays. The reasoning to voice: DNS says where to deliver, the network says whether delivery is possible, and the logs say who refused. Keeping those layers separate is the discipline this scenario grades.

Answer: Split-brain: internal resolvers are answering with public records instead of private ones. Verify from an internal host: dig app.example.com against the internal resolver versus a public one, then inspect which zone the internal resolver is authoritative for and what it forwards. Fixes: publish the record in the private zone or view, add a conditional forwarder, or remove an over-broad public record that should never have existed. Prevention is testing resolution from inside the perimeter, not just outside, which is the lesson this scenario attaches to split-horizon work.

Answer: Delegation has two sides and both have caches. The parent’s NS set and glue may still name the old servers, secondaries may still be configured on the old platform, and resolvers hold NS data under TTLs that are often a day or more, longer than record TTLs. Check dig ns your-domain against a TLD server to see the registry’s view, then query each old and new nameserver directly. Retire old servers only after weeks of watching their traffic decay, because killing them early converts stale caches into hard failures. That sequencing is what migration scenarios test.

Answer: Run dig +trace on the new name and read where the walk dies. If the TLD hands you the parent’s nameservers and the parent answers NXDOMAIN or nothing for the subdomain, the record is missing or sitting in the wrong zone, the common case. If the parent returns NS records for the subdomain but those servers fail or refuse, delegation is half-built: the child zone was never created or the glue is wrong. One trace localizes the break to record, parent-side delegation, or child-side zone, which is why +trace fluency anchors DNS interview questions at this tier.

Answer: Reproduce on their path: query that ISP’s resolvers directly with dig @their-resolver for affected names and classify the failure mode. Timeouts suggest path or capacity trouble; SERVFAIL suggests their validation or upstream; stale NXDOMAIN suggests their negative cache. Compare public resolvers from the same network to split ISP-resolver problems from last-mile problems. Your levers are usually indirect: keep every nameserver healthy, consider lower TTLs, and escalate with the evidence you collected. Provider-specific symptoms are a classic shape in scenario rounds about intermittent pain.

Answer: Validation broke: the DS at the parent, the DNSKEYs in the zone, and the signatures no longer line up for resolvers that cached an intermediate state. Confirm with dig +dnssec: check that RRSIGs are present, test against a validating public resolver, then dig +cd to prove the signatures exist but fail verification. Repair by republishing the correct DS and re-signing, and prevent with pre-publication rollovers: new DNSKEY live and DS updated before old signatures age out. Rollover breakage is the signature story of DNSSEC in DNS interview questions.

Answer: Machine-local causes first: check their hosts file for a pinned entry, their adapter settings for a forced or dead resolver, and browser-level DoH that bypasses the corporate resolver entirely. Then dig from that machine against its configured resolver and against a public one; a difference localizes the problem to the resolver path, and if dig is clean while the browser still strays, malware or a hijacking proxy becomes the suspect. Local-then-path ordering is the pattern this scenario tests, and it transfers to every only my machine ticket.

Answer: Start inside the pod: resolv.conf shows the cluster search list and ndots:5, so run dig external.com with a trailing dot to skip search-domain expansion and compare with the same lookup without it. Then test CoreDNS: dig kubernetes.default.svc.cluster.local from the pod to confirm cluster resolution works, and check CoreDNS logs and its upstream forwarders for timeouts. Typical fixes: trailing-dot FQDNs for external calls, dnsConfig to lower ndots, or NodeLocal DNSCache. Knowing the ndots multiplier is expected in modern platform interviews.

Answer: Transfer path first: from a secondary, dig axfr the-zone @primary over TCP to see whether a transfer even starts, and read its logs for REFUSED, which usually means the primary’s allow-transfer ACL lost the secondary’s address or a TSIG key mismatch followed a rotation. Then compare SOA serials on both sides: an unchanged serial means no edit was detected, so replication is healthy and simply had nothing to do. NOTIFY reachability and the expire timer round out the checklist. Serial plus ACL is the canonical pair for this scenario in DNS interview questions.

Answer: A transfer moves registration, not zones: the nameserver list at the registry may have been reset to the gaining registrar’s parking servers, or the zone was never created on the new DNS host, leaving delegation pointed at servers that answer nothing. Verify with dig @tld-server your-domain ns to see what the registry actually publishes, then check those servers. Restore the correct NS list first, confirm the zone exists and matches, and expect cached NXDOMAIN to linger by the negative TTL. Registrar-versus-zone separation is the exact lesson this entry in DNS interview questions teaches.

Answer: Geo or latency steering answers per region, and the unhealthy region’s state is stale. Confirm by querying the authoritative nameserver from vantage points in each region, or with dig +subnet spoofing client prefixes, and compare the answers. Then audit the routing policy’s health checks for that region: the probe may hit a different port or path than users do, may pass on the load balancer while backends are dead, or the region’s pool was never removed from the weighted set. Steering is only as good as its checks, and the coupling between them is what this scenario grades.

Answer: Audit the chain in order: did the health check ever flip, does the check endpoint exercise the failing component or just a static page, was the failure threshold short enough for the outage’s shape, and did resolvers honor the flip given every cached answer lived for the TTL? The classic killer is a check passing against the load balancer while everything behind it was down. Then fix the policy and rehearse, because untested failover is precisely why this scenario appears so often in DNS interview questions.

Answer: Local first: resolv.conf or the Windows adapter settings for a dead or foreign nameserver, VPN software hijacking the resolver, and systemd-resolved state via resolvectl status. Then test past the local layer: dig @1.1.1.1 example.com from the same machine, where success proves the path is fine and the configured resolver is the problem, usually a wrong DHCP option. Finally check the hosts file for overzealous entries pinning names. Local-to-path ordering is the entire answer, and saying it crisply wins the scenario.

Answer: Size-dependent failure: TXT payloads full of SPF includes or long DKIM keys push responses past 512 bytes, and something on the path mishandles the oversized case. Test: dig txt the-name, then dig +tcp txt the-name; if TCP always works while UDP fails, suspect an EDNS-hostile middlebox or a firewall dropping fragmented UDP. Fixes: trim the record toward the size and lookup limits, ensure TCP 53 passes end to end, and document that big-answer paths need TCP. This size-sensitive pattern recurs in mail-infrastructure troubleshooting.

Answer: Look at the SPF record: every include and mechanism costs DNS lookups, SPF allows ten, and marketing platforms are lookup-hungry, so the record now evaluates to permerror and strict receivers reject. Confirm with dig txt your-domain, count the lookups with an SPF checker, and restructure: collapse redundant includes, use IP mechanisms for your own stable ranges, or split per-sender SPF onto subdomains with aligned DMARC. The ten-lookup ceiling is a favorite trap in mail-adjacent questions because it fails everything at once.

Answer: The classic: the owner name was written without a trailing dot, so it parsed as relative to the origin and shop.example.com became shop.example.com.example.com. Confirm by digging the literal long name, where the record is sitting, and inspect the loaded zone with named-checkzone or dig axfr against the primary. Fix the dot, bump the serial, reload, and add a lint step to your pipeline, because this one-character outage is a rite of passage in zone-file war stories.

Answer: Inconsistent secondaries: if that region’s users are answered by an anycast site whose secondary never picked up the transfer, its answers stay stale until the expire timer forces it silent. Compare SOA serials from every nameserver: dig @each the-zone soa +short, and look for the outlier. Then check that site’s transfer logs, NOTIFY reachability, and whether the primary’s allow-transfer ACL excludes it. Per-server serial comparison is the exact tool this scenario exists to teach, and it takes two minutes once you know it.

Answer: Capacity and policy under load. Read the server logs: REFUSED often means rate limiting or ACLs spilling onto real clients, while SERVFAIL can follow backend overload or timeout storms against a stressed zone backend. Fixes in order: confirm authoritative-only configuration, retune rate-limit windows, scale horizontally, and move bulk traffic to managed anycast DNS with low TTLs so recursive caches absorb the spikes. How resolvers and authorities behave differently under load is a recurring theme in scale-focused DNS interview questions.

Answer: Bring evidence, not memory: timestamps of every zone change from version control or audit logs; SOA serials across all nameservers at incident time; resolver answers sampled from multiple public resolvers with dig, ideally captured live during the event; and packet captures on port 53 if the network path is suspected. Rule out the impostors too: hosts files, VPN resolvers, and application timeouts that merely look like DNS. The deliverable is a timeline of what every layer answered and when. Evidence-first closure is the habit senior DNS interview questions are designed to find.