Building-permits pods report failures talking to an internal API. One symptom is NXDOMAIN from dig; another is connection refused after a name resolves to the Service ClusterIP. What distinction should the admin draw?
Select an answer to reveal the explanation.
Short Explanation
Think of looking up a restaurant: NXDOMAIN is “that place isn’t in the phone book,” while connection refused is “you found the address but nobody opened the door.” DNS success only proves the name maps to an IP—usually the Service ClusterIP—not that a Pod is listening on the port. Fix the wrong layer: missing Service/DNS name versus empty endpoints or a crashed container.
Full Explanation
DNS failures and connect failures are different troubleshooting layers. NXDOMAIN indicates CoreDNS (or upstream) could not resolve the queried name—often a wrong Service name, namespace, or search domain. A successful A/AAAA answer followed by connection refused indicates resolution worked but the TCP handshake failed at the target IP and port, commonly because the Service has no ready endpoints or the process is not listening. NetworkPolicy drops and Service type myths do not redefine these two error classes.