Fun facts

Light trivia uncovered while writing this wiki.

"CoreDNS" is "Caddy" minus the web bits

The repository's first commit on 2016-03-18 starts the project as a hard fork of Caddy. Two of its first three commits are titled "Gut the readme as it is mostly Caddy" and "Slightly more text in the README for the time being." Within five months ("Make CoreDNS a server type plugin for Caddy (#220)" in Aug 2016) the project pivoted from being a fork of Caddy to being a plugin for Caddy — registering the dns server type instead of editing the framework. CoreDNS still imports a fork of Caddy v1 at github.com/coredns/caddy.

The proxy ghost

The proxy plugin was the original forwarder. It was deprecated in May 2018, replaced by forward in 2018, and finally removed in March 2019 (PR #2651). The empty EnableChaos map in core/dnsserver/server.go still mentions it:

var EnableChaos = map[string]struct{}{
    "chaos":   {},
    "forward": {},
    "proxy":   {},
}

That "proxy" entry has been a no-op for seven years. The deprecated plugin still lives in the tree to greet anyone who tries to use it.

The longest source file is a test

The biggest single Go file in the repository is plugin/kubernetes/handler_test.go at 1,189 lines. The biggest non-test file is plugin/kubernetes/controller.go at 910 lines — a hint at how rich Kubernetes service-discovery semantics actually are.

NSEC3 was never supported

The dnssec plugin's README ends with a deliberate "NSEC3 is not supported." Authenticated denial of existence uses NSEC black lies — synthesized NSEC records that prove "no name exists between A and ZZZZZ." Cheaper to compute on the fly than NSEC3, easier to reason about, and good enough for the threat model CoreDNS targets.

34% of the git history is dependency bumps

Of the 4,750 commits in the repository, around 1,613 (≈ 34%) come from dependabot[bot], dependabot-preview[bot], coredns-auto-go-mod-tidy[bot], or coredns[bot]. go.mod and go.sum show up in the top of the 90-day churn list with 67 and 66 commits respectively. CoreDNS pulls in heavy SDKs (AWS, Azure, GCP, Kubernetes), and bumping each subgroup independently produces a steady rain of PRs.

The default Corefile

Run ./coredns in a directory with no Corefile and it doesn't error. It quietly loads:

.:53 {
    whoami
    log
}

That default is hard-coded inside dnsserver.RegisterServerType's DefaultInput. It means a fresh build will at least answer DNS queries by echoing the client's IP address back to itself.

The plugin order is the only thing that matters in the Corefile

Three different orderings of the same Corefile body produce identical behavior. Plugin execution order comes from plugin.cfg, not from the order of directives in your Corefile. The Corefile order is just declarative.

60 plugins, three steering committee terms

The steering committee block at the top of CODEOWNERS lists five maintainers with terms ending 2025-11-21. CoreDNS is governed under the CNCF charter; the GOVERNANCE.md document explains how SC members are elected and rotated.

"Whoami" is the simplest plugin

plugin/whoami/whoami.go exists for one purpose: when no other plugin can answer, return the client's address as an A or AAAA record. The implementation is under 100 lines including license headers and comments.

The CoreDNS gRPC service has exactly one RPC

pb/dns.proto is twelve lines:

service DnsService {
    rpc Query (DnsPacket) returns (DnsPacket);
}

message DnsPacket {
    bytes msg = 1;
}

The whole DoG (DNS over gRPC) protocol is a single bytes field that carries a wire-format DNS message. CoreDNS provides both a server (the grpc_server plugin) and a client (the grpc plugin) that consume this contract.

Health and ready aren't the same plugin

Both run an HTTP listener, both return small status documents, but they answer different questions. /health says "this process is up" — it stays 200 OK during the lameduck shutdown window so a load balancer doesn't yank traffic before the queue drains. /ready says "this process can serve" — it goes 503 the moment shutdown begins and only goes 200 once every plugin's Readiness check passes. They cooperate but they don't share state.