Context
A short hostname is convenient until two workloads interpret it differently. In Kubernetes, the client Pod's namespace and resolver configuration influence how a name becomes a DNS query. CoreDNS may be healthy while an application asks for the wrong fully qualified name. Start by identifying what the client actually sends, rather than immediately restarting the DNS deployment.
You need the failing Pod, its namespace, the intended Service namespace, and permission to read those objects. The examples assume an existing diagnostic container has cat and nslookup. Substitute tools supported by your image; production images do not need extra packages installed during an incident.
1. Read the resolver configuration at the client
kubectl -n storefront exec web-0 -- cat /etc/resolv.conf
kubectl -n storefront get pod web-0 -o yaml
kubectl -n payments get service ledger -o wide
Check dnsPolicy, dnsConfig, and whether hostNetwork is enabled. The search list commonly includes namespace and cluster suffixes, but cluster domains can differ. Treat the observed configuration as the evidence. The policy named Default inherits node resolver settings; the usual Pod default is ClusterFirst. Host-networked workloads need particular attention because their policy can produce a different resolution path.
2. Compare short and explicit names
Run the same harmless lookup from the failing client context:
kubectl -n storefront exec web-0 -- nslookup ledger
kubectl -n storefront exec web-0 -- nslookup ledger.payments
kubectl -n storefront exec web-0 -- nslookup ledger.payments.svc.cluster.local.
The final name is illustrative: replace cluster.local with your actual cluster domain. A trailing dot requests an absolute name in conventional DNS tooling. Also compare the application's resolver behavior, since language runtimes and libraries can maintain their own caches or handle search expansion differently from nslookup.
3. Interpret ndots without treating it as a universal fix
The ndots option affects when a resolver first treats a name as absolute versus trying search suffixes. A hostname containing dots can still trigger search expansion. Extra failed candidate lookups can resemble intermittent DNS delay, especially when an upstream resolver is slow. That does not establish that CoreDNS itself has failed.
As an explicitly illustrative example, a Pod in storefront calls ledger while the intended Service lives in payments. Its short lookup first searches its own namespace. Using ledger.payments makes the namespace intention clear. If an external hostname behaves differently, compare an absolute lookup and application timing before considering a workload-specific dnsConfig change.
Diagnose the scope of the failure
| Observation | Useful interpretation | Next evidence |
|---|---|---|
| Explicit Service name works, short name fails | Namespace assumption | Client search list and configured hostname |
| Internal lookup works, external lookup fails | Upstream forwarding path | CoreDNS configuration and upstream errors |
| Tool works, application fails | Runtime resolver or cache | Application DNS settings and retry logs |
| Only host-networked Pods fail | DNS policy difference | dnsPolicy and generated resolv.conf |
When several unrelated clients fail, expand the investigation to the DNS Service, CoreDNS Pods, and permitted DNS traffic paths. Read the Corefile before proposing edits. A cluster-wide search or forwarding change can affect applications that were previously healthy, so validate any change in a representative test environment.
Verify and maintain the naming contract
Correct the application's hostname or its specific DNS policy when evidence supports that boundary. Repeat lookups from the same Pod type and perform a harmless application request. Verify cross-namespace access and external-name resolution separately; a successful public lookup cannot prove Service discovery.
Document the expected namespace-qualified names, cluster domain, and any custom resolver options. Include representative internal and external lookups in deployment diagnostics. Monitor lookup failures and application connection errors with enough context to distinguish names, namespaces, and upstream resolution. Preserve resolver output with incident notes so future comparisons reveal whether the client configuration changed.
Explore Clouvenix containers kubernetes for implementation and operational handover.