Free lesson · CKA Prep Program · Module 4: Services and networking

Diagnose DNS and Connectivity Failures

Connection refused, timeout, and NXDOMAIN look alike from the app. This lesson splits them layer by layer: pod DNS config, CoreDNS health, service plumbing, policy blocks.

12 min reading

Objectives

Trace a name from pod resolv.conf through CoreDNS to the answer
Use nslookup plus dig plus raw-IP tests to split DNS from network faults
Read CoreDNS logs and endpoints to find the failing layer
Fix the three classic causes: selector mismatch, policy block, dead DNS

Why this matters

Networking questions are the exam's favorite maze because every layer can produce the same symptom: the app cannot reach the backend. A fixed drill order (DNS config, DNS service, endpoints, policy, route) turns the maze into a checklist and prevents the classic waste of debugging routing when the selector is wrong.

Concepts

Pods resolve through CoreDNS at the cluster IP (kube-dns Service, usually 10.96.0.10) with search domains from resolv.conf: short names expand to <svc>.<ns>.svc.cluster.local. Test inside a pod with nslookup <svc> or a debug pod carrying dig. NXDOMAIN for a name that should exist means CoreDNS trouble or the wrong namespace; a resolved IP that times out means plumbing or policy.

CoreDNS itself is a Deployment with endpoints: kubectl get endpoints -n kube-system kube-dns must list addresses, and its logs show refused queries and loop errors plainly. Past DNS, the drill is endpoints (selector match), then policy (timeout from one pod but success from another), then node-level routing last. Raw-IP curl against a pod IP skips DNS entirely and splits the problem in one command.

Worked example

Frontend cannot reach api:8080, fixed drill in order:

# 1. DNS config inside the client pod
kubectl exec frontend-xxx -- cat /etc/resolv.conf
# nameserver 10.96.0.10, search ...svc.cluster.local
# 2. resolution itself
kubectl exec frontend-xxx -- nslookup api
# NXDOMAIN? -> CoreDNS: kubectl -n kube-system logs -l k8s-app=kube-dns
# resolves to 10.x? -> 3. endpoints
kubectl get endpoints api            # empty? fix the selector
# 4. direct pod IP bypasses DNS and service
kubectl exec frontend-xxx -- curl -m 5 http://<pod-ip>:8080/
# works by IP but not by name? DNS. fails by IP too? policy or app.
# 5. policy split: same curl from a second pod elsewhere

Each step eliminates a layer permanently. The drill ends at the first step that fails, and the fix lives at that layer, never deeper.

Exam notes

Short names resolve in the pod's own namespace only: cross-namespace needs api.other-ns or the FQDN. A scaled-to-zero CoreDNS answers nothing: check its replicas when every lookup fails at once. And stale conntrack or kube-proxy hiccups mimic app failure after Service edits: re-check endpoints before restarting anything.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

Break a fictional frontend-to-API path three different ways (wrong selector, deny-all policy, CoreDNS scaled to zero) and for each show the drill output at the step that catches it plus the one-line fix.

Pass criteria

All three breakages caught at the correct drill step with quoted output; fixes are selector correction, policy exception, and CoreDNS scale-back.