Plugins

CoreDNS plugins are the units of functionality. Each one lives at plugin/<name>/, registers itself with plugin.Register("name", setup), and contributes a Handler to a server block's plugin chain. The full list of in-tree plugins is the plugin.cfg file; this section groups them by purpose.

There are 60+ in-tree plugins. Rather than dedicating a page to each, this lens groups them into themed pages and points back to the per-plugin README.md (and man/coredns-<name>.7) for the user-facing docs. Each category page summarises what the plugins do, where they sit in the chain, and which other plugins they cooperate with.

Pages in this section

Page	Plugins
Backends and zone serving	file, auto, secondary, hosts, etcd, kubernetes, k8s_external, route53, azure, clouddns, nomad, transfer
Forwarding and caching	forward, grpc, cache, dns64, loop
Security	acl, dnssec, sign, tls, tsig, view
Observability	log, errors, prometheus/metrics, dnstap, trace, debug, pprof, health, ready
Transforms	rewrite, template, header, minimal, loadbalance, any, chaos, autopath, metadata
Transport	bind, tls, https, https3, quic, grpc_server, proxyproto, multisocket, timeouts, bufsize, nsid
Utility	root, geoip, cancel, debug, reload, local, import, whoami, erratic, on, deprecated

How plugins fit together

A request walks down the chain in zdirectives.go order. The general flow:

graph LR
    A[transport setup<br/>tls, proxyproto, ...] --> B[setup<br/>root, metadata, geoip]
    B --> C[observability<br/>trace, log, dnstap, errors]
    C --> D[behavior<br/>cache, rewrite, acl, header, dnssec]
    D --> E[transforms<br/>template, autopath, minimal]
    E --> F[zone serving<br/>file, auto, kubernetes, etcd, hosts, ...]
    F --> G[forwarders<br/>forward, grpc]
    G --> H[fallback<br/>erratic, whoami]

Things to keep in mind:

• The Corefile order doesn't matter. Plugin order is fixed by plugin.cfg.
• Some plugins must come before others. metadata must run before plugins that read metadata. cache must come before backends so it sits between the client and the slow lookup.
• Some plugins are "head" of the chain (terminal): a backend like file or kubernetes will usually answer or NXDOMAIN. The forward and grpc plugins are also typically terminal but the next rcode list lets a request fall through to a later plugin on REFUSED.
• Some plugins explicitly fall through to the next plugin. The fallthrough directive is a shared convention parsed by plugin/pkg/fall.

Where to read

• For a single plugin's user docs, read its README.md (also rendered to man/coredns-<name>.7).
• For Corefile conventions and shared parsing, see Patterns and conventions.
• For how a plugin gets compiled into the binary, see Build and code generation.
• For the bigger picture of how plugins are dispatched, see DNS server and Plugin system.