CoreDNS

CoreDNS is a DNS server built around plugins. DNS turns names into records that software can use. CoreDNS receives a DNS query, routes it through a configured plugin chain, and returns a DNS response.

That plugin model is the main idea. One plugin can read Kubernetes service data. Another can serve a zone file. Others can forward queries, cache responses, expose metrics, or report health. You assemble the DNS behavior you need instead of adopting one fixed server role.

CoreDNS is widely encountered as the DNS service inside Kubernetes. The Kubernetes plugin watches cluster data and answers service-discovery queries. Queries outside the cluster domain can pass to the forward plugin and then to upstream resolvers. CoreDNS also works outside Kubernetes as a forwarding server or an authoritative server backed by files and other data sources.

The mental model

Think in three layers:

1. A server block claims one or more DNS zones and, optionally, a port or protocol.
2. The server block enables plugins and supplies their configuration.
3. A query reaches the most specific matching server block, then moves through that server's plugin chain.

The configuration file is called the Corefile. This small example accepts queries for all names, caches eligible responses, and forwards misses to the resolvers listed by the host:

. {
    errors
    cache
    forward . /etc/resolv.conf
}

The first dot represents the DNS root zone, so this block can receive any query. The second dot tells forward to forward every name within that block. /etc/resolv.conf supplies the upstream resolver addresses.

The order you write plugin directives in a Corefile does not set runtime execution order. The CoreDNS build defines the plugin-chain order in plugin.cfg. Read each plugin's documentation to understand whether it answers, passes the request onward, or observes the eventual response.

Where CoreDNS fits in Kubernetes

Kubernetes gives workloads stable DNS names for Services. A normal Service can receive an A or AAAA record shaped like service.namespace.svc.cluster-domain. A headless Service can return the addresses of its ready endpoints instead of one cluster IP.

The kubernetes plugin implements the Kubernetes DNS-based service-discovery specification. It watches cluster objects and answers records for its configured zones. The forward plugin commonly handles names outside the cluster domain. The cache plugin reduces repeated work, while health, ready, and prometheus support operation of the DNS service.

This distinction matters during incidents. A failed lookup can come from the client search path, the Kubernetes data reflected by the plugin, the Corefile route, an upstream resolver, or the network between them. CoreDNS sits in the path, but it is not automatically the source of every DNS failure.

Common purposes

• Kubernetes service discovery: answer names derived from Services and endpoint data.
• DNS forwarding: proxy selected zones or all unmatched queries to upstream resolvers.
• Authoritative serving: answer a zone from a file or another supported backend.
• Policy and transformation: rewrite names, filter requests, or synthesize responses with purpose-built plugins.
• DNS observability: export Prometheus metrics, log queries when needed, and expose health and readiness endpoints.

Operational judgment

Start with the smallest plugin set that meets the requirement. Every plugin adds behavior that you must understand and observe. Enable errors for processing errors. Use prometheus for request and response metrics. Treat full query logging as a diagnostic tool because it adds load and can expose queried names.

Separate liveness from readiness. The health plugin reports whether the CoreDNS process can answer its health endpoint. The ready plugin reports whether readiness-aware plugins are ready. In Kubernetes, the kubernetes plugin reports ready after it has synchronized with the Kubernetes API.

Reloads also need observation. The reload plugin can apply a changed Corefile without stopping the process. If the new Corefile cannot be parsed, CoreDNS keeps running the previous configuration and logs an error. A running process therefore does not prove that your latest configuration took effect.

Limits and tradeoffs

CoreDNS is modular, but plugins available at runtime must be compiled into the binary. Adding an external plugin usually means building a custom binary and owning its update path.

CoreDNS can forward recursive queries to upstream resolvers, but the default distribution does not provide a native recursive resolver plugin. Use it as a forwarder when another resolver owns recursion, or build with an external recursive plugin when that design is justified.

Caching improves latency and reduces backend traffic, but it also means answers can remain visible until their time to live expires. Forwarding adds dependence on upstream availability and network behavior. In Kubernetes, forwarding to a resolver configuration that points back toward CoreDNS can create a loop; the loop plugin detects simple static forwarding loops during startup.

Choose CoreDNS when a small DNS server composed from explicit plugins fits the job, especially for Kubernetes service discovery and controlled forwarding. Choose another DNS implementation when you need a mature recursive resolver, a different operational model, or features that would require maintaining a custom CoreDNS build.

A useful learning path

1. Learn DNS names, zones, record types, response codes, recursion, and caching.
2. Read the CoreDNS manual sections on servers, server blocks, and plugin chains.
3. Build a minimal Corefile and inspect it with coredns -plugins and coredns -conf.
4. Study the exact plugin pages for every directive you deploy.
5. In Kubernetes, trace one Service lookup from a Pod through the DNS Service and the kubernetes plugin.
6. Add health, readiness, metrics, and a controlled reload process before operating CoreDNS as infrastructure.
7. Practice separating client, CoreDNS, Kubernetes API, upstream, and network failures during troubleshooting.