← Problem Library
K8s L4 K8S 1329 · 14 min

A Pod logs DNS timeouts only on fresh nodes

Old nodes resolve cleanly, yet newly joined nodes exhibit sporadic lookup failures because node-local DNS bootstrapped before its local path was complete.

K8sPlatform ReliabilityLevel 4Pro14 min
Scenario

A scaling event introduces fresh nodes and only workloads landing there begin showing intermittent DNS resolution failures.

What to check first
  • Identify the primary failure signal in the The Cache Started Before Its Own Node Plumbing Was Ready scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Check node-local DNS initialization ordering on new nodes before replacing CoreDNS.

Questions worth viewing together
What should you verify first when A Pod logs DNS timeouts only on fresh nodes appears?

Community-field Kubernetes problem inspired by node-local DNS discussions where fresh nodes served partial failures until the cache daemon restarted. Node-specific DNS failures often point to bootstrap order rather than to cluster-wide resolver health.

What usually causes A Pod logs DNS timeouts only on fresh nodes in production?

Teams often blame upstream DNS when the issue exists only on recently added nodes.

What should you document after resolving A Pod logs DNS timeouts only on fresh nodes?

Node-local DNS components should be validated against node bootstrap ordering in autoscaled clusters.