Introduction

CoreDNS caches DNS answers in memory so repeated lookups are fast and upstream resolvers do less work. During debugging, though, that same cache can hide recent changes and make a Kubernetes cluster look inconsistent until the cached records expire.

How CoreDNS Caching Works

CoreDNS usually runs as a Deployment in the kube-system namespace. Each pod keeps its own in-memory cache, so there is not one cluster-wide cache to flush with a single API call.

That leads to an important operational detail:

• if you have two CoreDNS replicas, each has its own cached answers
• flushing one pod does not flush the others
• restarting the pods is the normal practical way to clear cached entries

For most clusters, there is no separate "flush cache" command exposed through kubectl.

The Standard Kubernetes Fix: Restart CoreDNS

The usual way to clear the cache is a rollout restart of the CoreDNS Deployment:

kubectl -n kube-system rollout restart deployment/coredns
kubectl -n kube-system rollout status deployment/coredns

When the new pods start, their in-memory caches begin empty. This is the simplest and safest operational path because Kubernetes handles the pod replacement.

If you are not sure of the DNS component name in the cluster, inspect it first:

kubectl -n kube-system get deploy,pods | grep -i dns

Some environments still use different naming conventions, and managed clusters may add extra DNS components around CoreDNS.

Check the CoreDNS Corefile

Sometimes repeated cache problems are really TTL problems. The cache plugin is configured in the CoreDNS Corefile, which typically lives in a ConfigMap.

kubectl -n kube-system get configmap coredns -o yaml

A common configuration contains a line such as:

cache 30

That value controls how long answers may remain cached. If the cluster repeatedly serves stale answers for longer than expected, it may be better to tune the cache duration than to restart DNS components every time.

Verify From Inside the Cluster

Always test DNS from inside the cluster before and after a restart. That ensures you are checking the same network path your workloads use.

kubectl run dns-test --rm -it --restart=Never \
  --image=busybox:1.36 -- nslookup kubernetes.default.svc.cluster.local

For an external lookup:

kubectl run dns-test --rm -it --restart=Never \
  --image=busybox:1.36 -- nslookup example.com

Testing from a workstation outside the cluster is not the same thing, because it bypasses the in-cluster DNS path entirely.

When Restarting Does Not Solve It

If stale answers remain after restarting CoreDNS, the cache may not be the real source of the problem. Other layers can also retain DNS state:

• the application runtime may cache lookups
• a node-local DNS layer may still hold old answers
• the upstream DNS server may still be serving the old record
• the Kubernetes Service or Endpoints data may not have updated yet

In other words, restarting CoreDNS clears CoreDNS memory, not every cache in the system.

Operational Caution

Restarting CoreDNS is usually low risk in a healthy cluster, but it is still a control-plane networking action. In production, do it deliberately, watch the rollout, and verify pods become ready before assuming DNS is stable again.

If stale cache behavior is recurring, the better fix is usually to adjust TTLs, upstream DNS, or the application design instead of making restarts part of normal operations.

Common Pitfalls

Assuming there is one shared cluster-wide CoreDNS cache is incorrect. Each CoreDNS pod keeps its own in-memory entries.

Restarting only one pod in a multi-replica setup may leave other stale answers active on the remaining replicas.

Treating every DNS issue as a CoreDNS cache issue can send debugging in the wrong direction when the real problem is upstream DNS or application-side caching.

Skipping verification from inside the cluster makes it hard to prove whether the restart changed the behavior seen by workloads.

Using restarts as a routine fix instead of checking the configured cache TTL can hide a more durable configuration problem.

Summary

• CoreDNS cache is usually cleared in practice by restarting the CoreDNS pods.
• 'kubectl rollout restart on the CoreDNS Deployment is the standard operational approach.'
• Each CoreDNS replica has its own cache, so think per pod, not per cluster.
• Check the Corefile cache setting if stale answers keep recurring.
• Test lookups from inside the cluster before and after any restart.