dns-troubleshootinglisted

# DNS Troubleshooting Resolve the name yourself, at each layer, and find the first one that gives a different answer. ## Purpose **Use this when:** - `no such host`, `NXDOMAIN`, `SERVFAIL`, or `Temporary failure in name resolution`. - A name resolves to an old address after a DNS change. - Resolution is intermittent or slow. - A Kubernetes pod cannot resolve a Service name, or resolution takes hundreds of milliseconds. **Do not use this when:** - The name resolves and the connection fails — that is TCP; use `linux-network-debugging` or `kubernetes-networking`. - The failure is a TLS certificate name mismatch — use `tls-debugging`. **What this skill assumes:** `dig` or `drill`. `nslookup` and `ping` are poor DNS tools — they hide the response code, which is the most diagnostic field in the answer. ## Operating Procedure 1. **Get the exact error.** `NXDOMAIN`, `SERVFAIL` and a timeout mean three different things. 2. **Resolve from the failing context**, not from your laptop. A container, a host and a laptop have different resolvers, different search domains, and different caches. 3. **Walk the chain**: local cache → configured resolver → authoritative server. Find the first layer that disagrees. 4. **Check the record at the authority.** That is ground truth; everything else is a cache. 5. **Account for TTL.** Most "DNS is broken after a change" reports are a cache that has not expired. 6. **Fix at the layer that is wrong**, and verify from the original faili