A hostname resolves to an address you know is wrong. Using `dig`, how would you establish whether the bad answer is being served from a caching resolver or is what the authoritative nameservers actually publish?

## Three places an answer can come from When a name returns the wrong address, the answer originated in one of three places, and each demands a different fix: 1. **The authoritative nameservers for the zone** publish it — the record is genuinely wrong and someone must edit the zone. 2. **A recursive resolver's cache** holds an old copy that has not expired yet — you wait out the TTL or flush. 3. **Something local to this host** overrides it — a different class of problem, and one you rule in or out by seeing whether other hosts agree. `dig` is the instrument that tells them apart, because unlike an application it lets you choose *which server you ask*. ## Step one: what am I getting now? ```bash dig +short api.example.com ``` `+short` prints just the data. When you want the full picture, drop it and read the header line, which looks like `;; flags: qr rd ra;` plus a status such as `NOERROR`, `NXDOMAIN` or `SERVFAIL`. `NXDOMAIN` means the name does not exist; `SERVFAIL` from a recursive resolver, when the authoritative servers answer fine, usually points at a validation or upstream failure rather than a missing record. ## Step two: ask a different recursive resolver ```bash dig @9.9.9.9 api.example.com +short ``` If a public resolver returns the correct address and yours does not, the divergence is on your side and cache is the leading suspect. If both are wrong the problem is further out. ## Step three: bypass caches entirely with +trace ```bash dig +trace api.example.com ``` `+trace` makes dig do the iterative work itself: it starts from the root servers, follows the delegation to the TLD servers, follows that to the zone's nameservers, and prints each referral. Because dig is querying those servers directly, no recursive resolver's cache is involved. It answers the question "what does the delegation chain currently say?" — including whether the delegation itself is pointing at the wrong nameservers, which is a failure mode people forget exists. Caveats: `+trace` needs outbound access to arbitrary nameservers, which some networks block, and it resolves from *your* vantage point, so a zone that returns different answers by geography or by view will show you your own view. ## Step four: ask the authoritative servers directly ```bash dig NS example.com +short dig @ns1.example.com api.example.com ``` The header of that reply should contain `aa` — authoritative answer — meaning this server owns the zone rather than repeating what someone told it. If the authoritative servers publish the bad address, your investigation is over: the record is wrong, and no amount of flushing will help. Query *each* listed nameserver, because a common and confusing fault is one secondary that failed to transfer the latest zone and keeps serving the old record to a fraction of the internet. ## Reading cache evidence from the TTL The TTL in a recursive resolver's answer is not the zone's configured TTL; it is the *remaining* lifetime of the cached copy. Run the same query twice with a gap: ```bash dig api.example.com | grep -E '^api' sleep 30 dig api.example.com | grep -E '^api' ``` A TTL falling from 280 to 250 proves the answer came out of cache and tells you exactly how long until it expires. A TTL that resets to the zone's full value each time means you are getting fresh lookups. You can also ask a resolver to answer only from its cache with `dig +norecurse @resolver api.example.com`, which many resolvers honour by returning the cached record or nothing. ## Putting the combinations together - Authoritative correct, resolver wrong, TTL counting down → cache; wait or flush. - Authoritative wrong → fix the zone; everything downstream is behaving correctly. - Nameservers disagree with each other → a broken zone transfer to one secondary. - `+trace` shows a delegation to nameservers you do not recognise → the delegation at the parent is wrong, which is a registrar-level problem. ## What the interviewer is listening for Not flag recitation — the reasoning. The good answer establishes ground truth at the authoritative servers first, uses the TTL as physical evidence of caching rather than guessing, and knows that low TTLs are what make a planned change fast to propagate, which is why you lower them *before* a migration rather than during the incident.