How to contribute

CoreDNS is a CNCF-graduated project. Contributions follow the standard CNCF practices: GitHub PRs, the Developer Certificate of Origin, and project owners listed in CODEOWNERS. This page is the operational manual; the rule book is in .github/CONTRIBUTING.md and GOVERNANCE.md.

Where work picks up

Two starting points:

• The issue tracker — bugs and features tagged help wanted, good first issue.
• The Slack channel #coredns on https://slack.cncf.io. Used for discussion before opening a substantial issue.

Per CONTRIBUTING.md, before submitting a feature PR open an issue first and "claim" it so reviewers can give early feedback. For new plugins, the process is to start with the README.md alone (so the name and configuration syntax are settled before code review) and follow up with setup.go and the handler.

Sub-pages

Page	What it covers
Development workflow	Branches, PRs, sign-off, review expectations
Testing	go test, integration tests in test/, fuzz, race
Debugging	Logs, the debug and pprof plugins, common pitfalls
Patterns and conventions	Plugin layout, registration, logging, metrics, mutating responses
Tooling	Makefile, make gen, make.doc, golangci-lint, CI workflows

DCO

Every commit must carry a Signed-off-by line. Use git commit -s. Probot enforces this on every PR. From CONTRIBUTING.md:

As required by the CNCF's charter, all new code contributions must be accompanied by a Developer Certificate of Origin (DCO). CoreDNS uses Probot to enforce the DCO on pull requests.

The Signed-off-by line is your assertion that you wrote the patch (or have the right to submit it under Apache 2.0). Reviewers will not merge a PR with a missing sign-off.

PR review expectations

• Small PRs. "If possible make a pull request as small as possible, or submit multiple pull request to complete a feature." Reviewers prefer two 200-line PRs to one 500-line PR.
• Tests included. New code without tests is rarely merged. The codebase has a strong "if it isn't tested, it isn't done" culture.
• Updated docs. A new plugin must include a README.md. The make.doc workflow regenerates man/coredns-<name>.7 and fails CI if the README hasn't been updated.
• No drive-by reformatting. Lint issues unrelated to the change should land in their own PR.
• Owner approval. Plugin changes need an LGTM from at least one of the CODEOWNERS for that plugin's directory. Top-level changes need an SC member.

The PR template is in .github/PULL_REQUEST_TEMPLATE.md.

Definition of done

A change is "done" when:

1. CI is green: tests, lint, codegen verification, doc generation, codeql, scorecards, fuzz harness compile.
2. At least one (often two) CODEOWNERS of the touched directory have approved.
3. The DCO check passes.
4. Any new metric, configuration knob, or behaviour is documented in the relevant README.md and (if applicable) man/.
5. If the change touches plugin.cfg or the generators, core/plugin/zplugin.go and core/dnsserver/zdirectives.go are committed and match what make gen produces.

Governance

GOVERNANCE.md describes the steering committee, contributor ladder, and how new owners are added. The TL;DR:

• Reviewer. Anyone listed as a CODEOWNER for a directory.
• Maintainer. A reviewer with merge rights across the project. Earned through sustained contribution.
• Steering committee (SC). Five members elected for two-year terms. Members are listed at the top of CODEOWNERS. The SC handles project-wide decisions: governance changes, new plugin acceptance into the main repo, vendor relations.

Security disclosures

If you find a security issue, do not open a public issue. Email security@coredns.io. The full process is in .github/SECURITY.md. Two third-party audits have been published (Cure53 in Mar 2018 and Trail of Bits in Mar 2022).