Prompt and scope
This general technology question tests networking fundamentals and troubleshooting. The key is separating an updated authoritative record from an old answer held by a recursive resolver or client.
What the interviewer is testing
- Explaining the roles of a stub resolver, recursive resolver, and authoritative server.
- Correctly reasoning about TTL, negative caching, and independent record types.
- Using queries from multiple locations and resolvers to isolate a cache or delegation issue.
- Planning a reversible DNS cutover instead of merely telling users to clear caches.
Clarifying questions to ask
Confirm whether the change is A, AAAA, CNAME, or NS delegation; whether both endpoints are healthy; whether the issue is global or limited to a provider, region, or network; the old TTL and SOA negative-cache parameters; DNSSEC status; and whether the application pins results or uses connection pools.
The 30-second answer
I would query the authoritative server first, then compare the answer and remaining TTL from several public resolvers and affected networks. If authority is correct but recursion is old, the cache or an upstream TTL is responsible. If authority is inconsistent, inspect delegation, zone publication, and automation. Before cutover, lower TTL and wait through the old window, keep both endpoints healthy, observe traffic, and only then retire the old one.
Step-by-step deep dive
1. Draw the real query path
An application usually reaches a browser or OS stub resolver, which asks a recursive resolver. The recursive resolver returns a cached answer when it is fresh or follows the root, TLD, and authoritative servers when it is not. The authoritative server stores the zone’s record. Each layer can have its own cache and refresh timing.
2. Explain time with TTL and negative caching
Longer TTLs improve cache hit rate and reduce query load, but they delay changes. Existing cached answers generally remain until their old TTL reaches zero. Negative responses can also be cached according to SOA-related parameters, so a newly created name may still look absent. Measure remaining TTL per record type and resolver rather than promising one propagation duration.
3. Make the investigation repeatable
Query the authoritative server and verify consistent delegation. Then query the same name, type, and flags through multiple recursive resolvers, regions, and networks, recording answer, TTL, response code, and time. The patterns “authority correct, recursion old,” “authority inconsistent,” and “only one client old” point to cache, publication/delegation, and local layers respectively.
4. Rule out non-DNS stale addresses
HTTP proxies, CDNs, application configuration, connection pools, service discovery, or a hosts file can keep using an old address after DNS is correct. Check the actual destination IP, TLS certificate, response headers, and load-balancer logs to prove the failure is in resolution rather than routing or application caching.
5. Plan a safe cutover
Lower TTL to a business-acceptable value before the change and wait through the previous TTL window; keep old and new endpoints available together. After the change, monitor answer distribution, errors, and real traffic by region and resolver. Keep the old endpoint until the risk window closes, and prepare application-level degradation or dual service because DNS rollback also waits on caches.
A strong sample answer
I would verify the authoritative record and delegation first, then query several recursive resolvers and affected networks while recording answers and remaining TTL. An updated authority with an old recursive answer means cache expiry; inconsistent authority means zone publication, NS, or automation; a few anomalous devices point to local cache, hosts, proxy, or connection-pool state. TTL controls how long an old answer can be used, and negative caching affects new names, so I would not promise a fixed propagation time. I would lower TTL before the cutover, keep both endpoints active, monitor real traffic and errors, and retire the old endpoint only after the risk window.
Common mistakes
- Claiming DNS propagation always finishes in a few minutes.
- Clearing one laptop’s cache and treating that as global evidence.
- Querying only one public DNS provider.
- Updating A while forgetting AAAA, CNAME, NS, or DNSSEC.
- Shutting down the old service immediately after authority changes.
- Blaming DNS when a CDN, proxy, or hosts file serves the old address.
Follow-up questions and responses
Why does a new record still return NXDOMAIN?
An upstream resolver may have cached the negative response under SOA-related parameters. Confirm the authoritative record exists and wait for negative-cache expiry.
Why is the old answer present after lowering TTL?
Lowering TTL affects newly fetched cache entries; existing entries still count down their old TTL. Also verify the correct record, zone, and authoritative server were changed.
Can you force every user to refresh DNS?
No. Recursive resolvers and clients are outside your control. Reduce risk with an early TTL change, dual endpoints, application routing, and monitoring.
How do you detect IPv6 as the cause?
Query and test A and AAAA separately, recording the address family actually used by clients. If AAAA still points to the old endpoint, fix it independently.