Need help with coredns?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

8.3K Stars 1.5K Forks Apache License 2.0 2.9K Commits 48 Opened issues


CoreDNS is a DNS server that chains plugins

Services available


Need anything else?

Contributors list


Documentation CodeQL Go Fmt Go Tests Go Tidy CircleCI Code Coverage Docker Pulls Go Report Card CII Best Practices

CoreDNS is a DNS server/forwarder, written in Go, that chains plugins. Each plugin performs a (DNS) function.

CoreDNS is a Cloud Native Computing Foundation graduated project.

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins. If some functionality is not provided out of the box you can add it by writing a plugin.

CoreDNS can listen for DNS requests coming in over UDP/TCP (go'old DNS), TLS (RFC 7858), also called DoT, DNS over HTTP/2 - DoH - (RFC 8484) and gRPC (not a standard).

Currently CoreDNS is able to:

  • Serve zone data from a file; both DNSSEC (NSEC only) and DNS are supported (file and auto).
  • Retrieve zone data from primaries, i.e., act as a secondary server (AXFR only) (secondary).
  • Sign zone data on-the-fly (dnssec).
  • Load balancing of responses (loadbalance).
  • Allow for zone transfers, i.e., act as a primary server (file + transfer).
  • Automatically load zone files from disk (auto).
  • Caching of DNS responses (cache).
  • Use etcd as a backend (replacing SkyDNS) (etcd).
  • Use k8s (kubernetes) as a backend (kubernetes).
  • Serve as a proxy to forward queries to some other (recursive) nameserver (forward).
  • Provide metrics (by using Prometheus) (prometheus).
  • Provide query (log) and error (errors) logging.
  • Integrate with cloud providers (route53).
  • Support the CH class:
    and friends (chaos).
  • Support the RFC 5001 DNS name server identifier (NSID) option (nsid).
  • Profiling support (pprof).
  • Rewrite queries (qtype, qclass and qname) (rewrite and template).
  • Block ANY queries (any).
  • Provide DNS64 IPv6 Translation (dns64).

And more. Each of the plugins is documented. See for all in-tree plugins, and for all out-of-tree plugins.

Compilation from Source

To compile CoreDNS, we assume you have a working Go setup. See various tutorials if you don’t have that already configured.

First, make sure your golang version is 1.12 or higher as

go mod
support is needed. See here for
go mod
details. Then, check out the project and run
to compile the binary:
$ git clone
$ cd coredns
$ make

This should yield a


Compilation with Docker

CoreDNS requires Go to compile. However, if you already have docker installed and prefer not to setup a Go environment, you could build CoreDNS easily:

$ docker run --rm -i -t -v $PWD:/v -w /v golang:1.16 make

The above command alone will have

binary generated.


When starting CoreDNS without any configuration, it loads the whoami and log plugins and starts listening on port 53 (override with

), it should show the following:
linux/amd64, go1.13.5, aa8c32

The following could be used to query the CoreDNS server that is running now:

dig @ -p 53

Any query sent to port 53 should return some information; your sending address, port and protocol used. The query should also be logged to standard output.

The configuration of CoreDNS is done through a file named

. When CoreDNS starts, it will look for the
from the current working directory. A
for CoreDNS server that listens on port
and enables
plugin is:
.:53 {

Sometimes port number 53 is occupied by system processes. In that case you can start the CoreDNS server while modifying the Corefile as given below so that the CoreDNS server starts on port 1053.

.:1053 {

If you have a Corefile without a port number specified it will, by default, use port 53, but you can override the port with the

coredns -dns.port 1053
, runs the server on port 1053.

A Corefile for a CoreDNS server that forward any queries to an upstream DNS (e.g.,
) is as follows:
.:53 {
    forward .

Start CoreDNS and then query on that port (53). The query should be forwarded to and the response will be returned. Each query should also show up in the log which is printed on standard output.

To serve the (NSEC) DNSSEC-signed
on port 1053, with errors and logging sent to standard output. Allow zone transfers to everybody, but specifically mention 1 IP address so that CoreDNS can send notifies to it. {
    file /var/lib/coredns/
    transfer {
        to * 2001:500:8f::53

on port 1053, but forward everything that does not match
to a recursive nameserver and rewrite ANY queries to HINFO. {
    file /var/lib/coredns/
    transfer {
        to * 2001:500:8f::53

. { any forward . errors log }

IP addresses are also allowed. They are automatically converted to reverse zones: {

Means you are authoritative for

This also works for IPv6 addresses. If for some reason you want to serve a zone named
add the closing dot:
as this also stops the conversion.

This even works for CIDR (See RFC 1518 and 1519) addressing, i.e.
, CoreDNS will then check if the
request falls in the correct range.

Listening on TLS (DoT) and for gRPC? Use:

tls:// grpc:// {

And for DNS over HTTP/2 (DoH) use: {
    tls mycert mykey

Note that you must have the tls plugin configured as DoH requires that to be setup.

Specifying ports works in the same way:

grpc:// {
    # ...

When no transport protocol is specified the default

is assumed.


We're most active on Github (and Slack):

More resources can be found:

Contribution guidelines

If you want to contribute to CoreDNS, be sure to review the contribution guidelines.


Examples for deployment via systemd and other use cases can be found in the deployment repository.

Deprecation Policy

When there is a backwards incompatible change in CoreDNS the following process is followed:

  • Release x.y.z: Announce that in the next release we will make backward incompatible changes.
  • Release x.y+1.0: Increase the minor version and set the patch version to 0. Make the changes, but allow the old configuration to be parsed. I.e. CoreDNS will start from an unchanged Corefile.
  • Release x.y+1.1: Increase the patch version to 1. Remove the lenient parsing, so CoreDNS will not start if those features are still used.

E.g. 1.3.1 announce a change. 1.4.0 a new release with the change but backward compatible config. And finally 1.4.1 that removes the config workarounds.


Security Audit

A third party security audit was performed by Cure53, you can see the full report here.

Reporting security vulnerabilities

If you find a security vulnerability or any security related issues, please DO NOT file a public issue, instead send your report privately to

[email protected]
. Security reports are greatly appreciated and we will publicly thank you for it.

Please consult security vulnerability disclosures and security fix and release process document

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.