Articles

DNS Troubleshooting Interview Questions: Caches, TTLs, and Split-Horizon Answers

Prepare for DNS troubleshooting interviews with TTL timelines, negative caching, split-horizon answers, and resolver-specific evidence.

You lower a DNS record's TTL to 60 seconds, change its address, and wait a minute. Some clients still connect to the old server. Meanwhile, the hostname resolves correctly from your laptop but returns NXDOMAIN inside the production VPC. “DNS propagation” is too vague to explain either result.

Strong DNS troubleshooting interview answers preserve three things: the exact question, the resolver path, and the observation time. An address without that context can be a perfectly valid answer from the wrong DNS view or an old cache entry that has not expired.

Evidence boundary: The protocol explanations below use IETF standards. Command behavior comes from ISC BIND documentation, and the private-zone example is explicitly specific to Amazon Route 53. Timelines and diagnostic exercises are original interview practice, not candidate reports or claims about an employer's question frequency. Try Troubleshoot CPU, latency, and DNS issues while keeping each proposed cause tied to an observable result.

What information belongs in a DNS incident report?

Official protocol fact: DNS distinguishes query names, record types, classes, response codes, and resource-record TTLs. An A query and an AAAA query are different questions even when they use the same hostname. RFC 1035

Original diagnostic method: Record the fully qualified name, record type, resolver address, client environment, timestamp, response status, answer, and returned TTL. Include relevant authority information when diagnosing negative answers. Preserve the actual output rather than transcribing only an IP address.

For example, “api.example.com. A through the VPC resolver from the application container at 10:02 UTC returns NXDOMAIN” is actionable. “The domain is broken” hides the distinctions you need to investigate.

Also identify the process that failed. A command-line lookup from a developer laptop may use a different resolver path from a browser, application runtime, container, or VPN-connected workload. Treat those differences as variables to measure. Do not assume all programs on one machine share an identical cache and resolution configuration.

Your first interview answer should therefore ask for the failing environment and exact query before proposing a cache flush or zone edit.

Why doesn't lowering TTL invalidate existing caches?

Official foundation: DNS uses distributed caching with lifetimes supplied by resource records. Updating authoritative data does not synchronously replace every previously cached copy. RFC 1034

Original timeline exercise: Assume an ordinary positive cache, no prefetch or stale-serving behavior, and a record initially carrying a 300-second TTL. The old address is 192.0.2.10; the replacement is 192.0.2.20. These are documentation addresses.

Time	Event	Consequence under the stated assumptions
10:00:00	Resolver A caches the old address with TTL 300	Its ordinary expiry is 10:05:00
10:01:00	Authoritative TTL is lowered to 60	Resolver A's existing entry is not retroactively rewritten
10:02:00	Authoritative address changes	Fresh authoritative responses contain the new address
10:03:00	Client asks Resolver A	Old address may still be returned with about 120 seconds remaining
After 10:05:00	Resolver A refreshes successfully	It can obtain the replacement address

The useful calculation is based on when that resolver cached the answer and the lifetime it received. Counting 60 seconds from the control-panel edit uses the wrong starting point.

For a planned migration, lower TTL sufficiently before the address change to allow earlier positive entries to expire. Then verify authoritative responses and representative recursive paths. The appropriate waiting period follows the previous data and actual resolver behavior; it is not a universal internet-wide number.

A rollback needs the same reasoning. Switching the authoritative address back does not retract copies of the replacement address already cached elsewhere. Keep both destinations' operational state in the recovery plan when the service design permits it.

What do NXDOMAIN, NODATA, and SERVFAIL mean?

Official negative-answer fact: RFC 2308 distinguishes a nonexistent name from a name that exists but lacks the requested record type. NODATA is an interpretation of response contents, not a separate wire response code; negative answers can be cached using the specified SOA-derived lifetime. RFC 2308

Official update: Resolution failures can also be cached. RFC 9520 updates requirements for caching failures, so “SERVFAIL is never cached” is an unsafe troubleshooting assumption. RFC 9520

Interview reasoning: Use the response to choose the next question.

Result	Next investigation	Tempting but unsupported conclusion
NXDOMAIN	Which name or alias target was judged nonexistent in this view?	The name cannot exist anywhere
NOERROR with no requested data	Inspect answer, authority, aliases, and requested type	Every empty answer means NXDOMAIN
SERVFAIL	Inspect resolver diagnostics and upstream or validation failure evidence	The domain was deleted
No response before timeout	Check resolver reachability and query/response transport	The server explicitly returned a negative answer

Suppose you create a record after a client previously received NXDOMAIN. That client may still encounter a cached negative response. Inspect its lifetime and source before repeatedly recreating the record.

A record-specific TTL change is not necessarily the lifetime governing a previously cached negative answer. This is why preserving the authority section and failure context is more useful than repeatedly running a command that shows only successful address values.

Why can an expired answer still appear?

Official exception: RFC 8767 describes serving stale DNS data to improve resilience when refresh attempts cannot obtain fresh information. Actual use depends on resolver implementation and configuration. RFC 8767

Interview reasoning: The ordinary timeline above deliberately excluded this behavior. If observed results extend beyond its assumptions, investigate the resolver rather than declaring the TTL meaningless.

Ask whether refresh attempts are failing, whether stale serving is enabled, and whether you are looking at DNS data at all. An application may be reusing an already-established connection to the old endpoint. In that case, observing old-server traffic does not establish that a fresh DNS query returned the old address.

Separate three observations: the resolver's current answer, the application's selected destination for a new connection, and the destination of an existing connection. A DNS migration can succeed at the first boundary while older connections remain active at the third.

Avoid changing several cache layers and restarting the application simultaneously. You may restore service but lose the evidence needed to explain which boundary was responsible.

Why does public DNS work while the VPC returns NXDOMAIN?

Official AWS behavior: Route 53's documented private-zone behavior does not simply fall back to public DNS when a matching private hosted zone lacks the requested name and type. Its considerations page describes an NXDOMAIN response in that situation, and also documents precedence involving overlapping zones and Resolver rules. Route 53 private hosted zone considerations

Original scenario: Public DNS contains api.example.com., while a private example.com zone is associated with the workload's VPC. The private zone has another service record but no entry for the API. A public lookup succeeds; the workload's lookup fails.

The public result is useful evidence that the public view has an answer. It does not prove the private resolver is consulting that view. Inspect zone associations and forwarding rules before changing the public record.

Use a small comparison matrix:

Vantage point	Query path to record	Purpose
Public test environment	Its intended public resolver	Establish the public answer
Failing workload	Its actual configured resolver	Reproduce the affected view
Another workload in the same VPC	Its actual resolver	Separate workload-local configuration from shared view
Approved administrative inspection	Private zone and forwarding configuration	Explain why the resolver selected that namespace

The fix depends on intended architecture. It might be adding the appropriate private record, correcting a zone association, or repairing a forwarding rule. Do not remove a private zone merely because a public query works; other private services may depend on it.

What does dig prove, and what does it miss?

Official tool behavior: ISC documents explicit server selection, query types, recursion options, and +trace. The trace option follows delegation through iterative queries; supplying @server with trace affects its initial root-server lookup, not every subsequent query. BIND dig documentation

Original command exercise: Substitute the resolver you are authorized to test for the documentation address below. These commands illustrate evidence collection; they have not been run against your infrastructure.

dig @192.0.2.53 api.example.com. A
dig @192.0.2.53 api.example.com. AAAA
dig @192.0.2.53 api.example.com. A +tcp

Compare the full output: answering server, status, answer, authority, and time. Changing to TCP is a transport comparison, not a permanent fix by itself. A successful comparison suggests where to investigate; it does not identify the particular device or policy causing a UDP failure.

An authoritative query can establish what a particular authoritative server currently serves. It does not establish what the affected recursive resolver cached. Likewise, a public delegation trace is not a reproduction of a private forwarding path.

Keep the trailing dot when you intend the absolute name. If the application uses a short name, investigate its search configuration separately. Replacing that name with a fully qualified name changes the experiment and should be reported as such.

How would you verify a DNS change without fooling yourself?

Original verification plan: Define the expected answers separately for public and private clients before making the change. Include both address families when the application uses them. Record the old TTL and the expected service destination, not just the new DNS value.

Afterward, verify the authoritative view, representative recursive views, and an actual new application connection from the affected environment. Keep timestamps with every observation. If the application reuses connections, choose a controlled method to distinguish a fresh connection without disrupting unrelated traffic.

A convincing answer also describes rollback evidence. If the new destination fails health checks, identify which clients may still have it cached and how long both destinations must remain supported under the plan's assumptions. Avoid promising immediate reversal from a single DNS edit.

Finish by separating what you proved from what you inferred: “The private resolver returns the intended address for this exact query; the application opens a new connection to that address and completes a request. Existing connections were not part of this test.”

Practice DNS diagnosis and cache reasoning

The cache exercises are not DNS protocol implementations; use them to practice expiration and incident reasoning without claiming they reproduce every resolver rule.

Question	Relevant practice
Troubleshoot CPU, latency, and DNS issues	Distinguish resolution delay from other latency
Explain VPCs and private/public network connectivity	Explain resolver view and workload location
Explain How Microservices Run and Fail on Kubernetes	Reproduce from the application's environment
Implement a Key-Value Cache with Per-Entry Expiration	Reason about insertion time and expiry
Debug a cache incident end-to-end	Separate fresh source data from cached observations

Return to Troubleshoot CPU, latency, and DNS issues and answer with an exact query, resolver path, timeline, and one test that could disprove your leading hypothesis.