CoreDNS

What it is

CoreDNS is a DNS server written in Go, built around a plugin chain architecture — each request passes through a configurable sequence of plugins (kubernetes, forward, cache, hosts, prometheus, etc.) defined in a Corefile. It's the default cluster DNS provider in Kubernetes since 1.13, replacing kube-dns, and it also runs standalone for general-purpose DNS, service discovery, and DNS-based traffic control outside of Kubernetes entirely.

If you've run a Kubernetes cluster in the last five years, you've run CoreDNS whether you noticed it or not. It resolves .svc.cluster.local names, handles pod DNS policy, and is usually the first thing to blame (rightly or wrongly) when service-to-service resolution breaks.

Who builds it and why

CoreDNS is a CNCF graduated project — one of the earlier graduates, reflecting its status as critical, boring, load-bearing infrastructure rather than a hot new tool. It has 494 contributors on GitHub and an active commit history through mid-2026, which for a project this mature signals it's still getting maintenance attention, not just coasting on inertia. Development is driven by the plugin model: most contributors extend or maintain specific plugins rather than touching core, which keeps the blast radius of changes small and lets the project absorb contributions from people who only care about their one plugin.

Production readiness signal

CoreDNS is about as production-proven as infrastructure software gets — it's been the default DNS layer for Kubernetes for years, running in effectively every cluster on every major cloud and on-prem distro. 14,150 GitHub stars undersells its actual footprint, since most users never interact with the repo directly; they just inherit it as a cluster component.

Latest release is v1.14.4, indicating a mature, incrementally-versioned project rather than one still finding its API. Known operational failure modes are well-documented at this point: NodeLocal DNSCache is the standard mitigation for conntrack/UDP DNS issues at scale, and the "5-15 second DNS lookup delay" bug from ndots:5 + concurrent A/AAAA queries is a known pattern most platform teams have had to tune around at some point. That the ecosystem has converged on standard fixes for these issues is itself a maturity signal — the failure modes are known and solved, not open questions.

Who should use this

Anyone running Kubernetes is already using CoreDNS — the more relevant question is whether you should touch the Corefile yourself. You should if you need custom DNS routing (split-horizon, rewriting internal domains), you're debugging cluster DNS latency/failure issues, you need DNS-based service discovery outside Kubernetes, or you're building a custom plugin for internal DNS policy (rate limiting, logging, custom backends).

Who should NOT use this

Don't reach for CoreDNS if you need a full-featured external-facing authoritative DNS server with a polished UI, DNSSEC tooling, and registrar integration — use BIND, PowerDNS, or a managed DNS provider instead. Don't use it as a general-purpose DNS caching/forwarding resolver on end-user devices or non-Kubernetes edge networks unless you're already comfortable operating Go infrastructure — dnsmasq or Unbound are lighter and more purpose-built there. And don't assume you need to hand-tune the Corefile at all if you're not hitting a specific documented problem — the default Kubernetes config is fine for the vast majority of clusters, and unnecessary tinkering is a common source of self-inflicted DNS outages.

Alternatives

• kube-dns — CoreDNS's predecessor; deprecated, effectively unmaintained, don't start new clusters on it.
• dnsmasq/Unbound — lightweight, non-pluggable resolvers better suited to simple forwarding/caching outside Kubernetes.
• BIND/PowerDNS — full authoritative DNS servers for external-facing zones, registrar-integrated DNS, DNSSEC.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no commercial entity behind it. Cost is entirely your own operational overhead — running it is free, running it correctly at scale is where the engineering time goes.