Pod DNS Not Working - Part 1

Why It Matters

Accurate DNS debugging prevents service outages and performance degradation in Kubernetes, directly protecting application reliability and business continuity.

Key Takeaways

• Pods rely on DNS, not static IPs, for service discovery.
• /etc/resolv.conf points pods to the kube-dns/CoreDNS service for name resolution.
• Test with kubernetes.default and google.com to isolate DNS issues.
• Failure patterns indicate cluster DNS, external DNS, or misconfiguration.
• Timeouts vs NXDOMAIN reveal connectivity or name resolution problems.

Summary

The video walks through a classic Kubernetes interview scenario: a pod cannot resolve DNS names and the engineer must pinpoint the failure point. It stresses that pods rarely use static IPs; instead they depend on the cluster’s DNS service (CoreDNS) to translate service names into IPs, making name resolution essential for dynamic workloads. The presenter outlines the DNS lookup chain: a pod reads /etc/resolv.conf, which points to the kube-dns service; the request reaches a CoreDNS pod, which resolves internal names like kubernetes.default and forwards external queries (e.g., google.com) to upstream resolvers. By running two simple dig or nslookup commands—one for an internal service and one for an external domain—operators can quickly isolate whether the problem lies in cluster DNS, external DNS, or network connectivity. He explains the diagnostic matrix: if both lookups fail, CoreDNS or network firewalls are likely down; if only the external lookup fails, forwarding or upstream DNS is broken; if only the internal lookup fails, the pod may be querying the wrong DNS server. The type of error matters too—NXDOMAIN signals a non‑existent name, while a timeout indicates the pod never reached a DNS server. Understanding this flow lets teams troubleshoot DNS outages faster, reducing application latency and downtime. It also highlights that seemingly “slow” DNS may simply be excessive retries rather than a true failure, guiding operators toward more precise remediation.

Original Description

Can you debug a Kubernetes DNS failure in 2 commands? 👇

Most engineers can't. Here's the trick senior SREs use 👇

If your first instinct is to dive into CoreDNS logs — stop. There's a 2-command test that tells you exactly where the problem is before you waste 30 minutes debugging.

Run these inside the broken pod:

1. nslookup kubernetes.default

2. nslookup google.com

The pass/fail pattern is your map:

🔴 Both fail → cluster DNS or firewall issue

🟡 Internal works, external fails → CoreDNS forwarding broken

🟠 Internal fails, external works → wrong DNS server in /etc/resolv.conf

🟢 Both work but slow → DNS isn't broken, it's overloaded

Also watch HOW it fails:

- "No such host" = name doesn't exist

- "Timeout" = never reached the DNS server

Save this for your next K8s outage 🔖

Part 2 coming — when cluster DNS itself is dead.

#kubernetes #k8s #devops #coredns #kubernetesdns #kubernetestutorial #devopsinterview #kubernetesinterview #cloudnative #sre #kubectl #cka #ckad #kubernetestips #devopsengineer #containerization #k8stutorial #cloudengineer #kubernetesshorts #kubernetestroubleshooting