What is CoreDNS and Why Does Kubernetes Use It?
Learn what CoreDNS is, its plugin-based architecture, and why Kubernetes uses it as the default cluster DNS server.
Expected Interview Answer
CoreDNS is a flexible, plugin-based DNS server written in Go that Kubernetes runs as the default cluster DNS provider, translating Service and Pod names into IP addresses by dynamically reading state from the Kubernetes API.
CoreDNS replaced the older kube-dns as the default cluster DNS add-on because its chain-of-plugins architecture lets operators compose exactly the DNS behavior they need — the kubernetes plugin serves cluster records, the forward plugin sends external queries upstream, the cache plugin reduces repeated lookup latency, and the errors and health plugins support observability. CoreDNS itself runs as a standard Kubernetes Deployment (typically two or more replicas for availability) fronted by a Service, and its entire configuration lives in a Corefile stored as a ConfigMap, so operators change DNS behavior declaratively like any other cluster resource. Because it watches the API server directly rather than polling, DNS records for Services and Pods update within moments of any change, with no external database or sync process required. In very large clusters, teams add NodeLocal DNSCache as a per-node caching layer in front of CoreDNS to reduce query latency and load on the central CoreDNS Pods.
- Plugin architecture lets DNS behavior be composed declaratively
- Configuration lives in a version-controllable Corefile ConfigMap
- Watches the API server directly for near-instant record updates
- Scales via replica count and optional per-node caching layers
AI Mentor Explanation
CoreDNS is like a stadium’s in-house announcement system built from swappable modules — one module reads the live team sheet, another relays outside broadcast feeds, another caches recent announcements to avoid repeating itself constantly. Ground staff configure exactly which modules run and in what order via a single settings sheet, rather than rewiring the whole announcement system for each change. The system listens directly to the scorer’s live feed rather than checking in periodically, so a substitution announcement goes out within seconds. Large stadiums add extra local speaker relays near each stand to reduce the load on the central announcement booth during a packed match.
Step-by-Step Explanation
Step 1
CoreDNS deploys as a Deployment
Kubernetes runs CoreDNS Pods (usually 2+ replicas) behind a stable kube-dns Service.
Step 2
Corefile defines plugin chain
A ConfigMap holds the Corefile, declaring which plugins (kubernetes, forward, cache, health) are active and in what order.
Step 3
API watch feeds live records
The kubernetes plugin watches Services and Endpoints directly via the API server, no polling delay.
Step 4
Scale for large clusters
Increase CoreDNS replicas and optionally add NodeLocal DNSCache to reduce latency and central load.
What Interviewer Expects
- Understanding that CoreDNS is a plugin-chain DNS server, not a monolithic binary
- Knowledge that its configuration (Corefile) lives in a ConfigMap
- Awareness that CoreDNS replaced kube-dns as the Kubernetes default
- Ability to name at least the kubernetes, forward, and cache plugins and their roles
Common Mistakes
- Assuming CoreDNS is external to the cluster rather than running as Pods inside it
- Not knowing configuration changes go through the Corefile ConfigMap
- Confusing CoreDNS with an external managed DNS service like Route 53
- Forgetting that scaling CoreDNS replicas is a valid mitigation for DNS latency issues
Best Answer (HR Friendly)
“CoreDNS is the DNS server that runs inside our Kubernetes cluster and lets services find each other by name. It is built from small, composable plugins, and we control its behavior through a single configuration file, so it is easy to reason about and change safely as our cluster grows.”
Code Example
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
forward . /etc/resolv.conf
cache 30
}Follow-up Questions
- What replaced kube-dns and why did Kubernetes switch to CoreDNS?
- How would you scale CoreDNS to handle DNS latency in a large cluster?
- What does the forward plugin do in a Corefile?
- How would you debug CoreDNS if Pods suddenly could not resolve Service names?
MCQ Practice
1. What architecture does CoreDNS use to define its behavior?
CoreDNS is built around a plugin chain, configured declaratively via a Corefile, allowing operators to compose exactly the behavior needed.
2. Where is the CoreDNS Corefile stored in a Kubernetes cluster?
The Corefile is stored in a ConfigMap, letting operators edit CoreDNS behavior declaratively like any other cluster resource.
3. What did CoreDNS replace as the default Kubernetes cluster DNS add-on?
CoreDNS replaced the older kube-dns add-on as the Kubernetes default due to its more flexible plugin architecture.
Flash Cards
What is CoreDNS? — The default plugin-based DNS server Kubernetes runs for cluster service discovery.
Where does CoreDNS store its configuration? — In a Corefile inside a ConfigMap in the kube-system namespace.
What did CoreDNS replace? — kube-dns, the earlier Kubernetes default DNS add-on.
How do large clusters reduce DNS latency? — By scaling CoreDNS replicas and adding NodeLocal DNSCache.