← Problem Library
K8s L4 K8S 1301 · 14 min

An initContainer loops on DNS for a dependency that already exists because CoreDNS negative caching outlives the service creation race during rollout

The dependency service appears moments later, yet the initContainer keeps failing because the resolver cached the earlier NXDOMAIN response.

K8sPlatform ReliabilityLevel 4Pro14 min
Scenario

A rollout creates both a dependency service and a consuming workload, and only the first few pods never recover from DNS failures.

What to check first
  • Identify the primary failure signal in the Service Exists Now but DNS Negative Cache Still Wins 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 resolver negative TTL behavior before rewriting the dependency ordering logic.

Questions worth viewing together
What should you verify first when An initContainer loops on DNS for a dependency that already exists appears?

Community-field Kubernetes problem inspired by Discuss Kubernetes patterns where init containers kept failing after a transient NXDOMAIN race. Some startup DNS races survive well after the service itself becomes healthy.

What usually causes An initContainer loops on DNS for a dependency that already exists in production?

Teams often blame NetworkPolicy when the real blocker is cached NXDOMAIN state.

What should you document after resolving An initContainer loops on DNS for a dependency that already exists?

Bootstrap flows that depend on immediate DNS visibility should consider negative cache behavior.