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:
version.bind
and friends (chaos).And more. Each of the plugins is documented. See coredns.io/plugins for all in-tree plugins, and coredns.io/explugins for all out-of-tree plugins.
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 make
to compile the binary:
$ git clone https://github.com/coredns/coredns
$ cd coredns
$ make
This should yield a coredns
binary.
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.12 make
The above command alone will have coredns
binary generated.
When starting CoreDNS without any configuration, it loads the
whoami and log plugins
and starts listening on port 53 (override with -dns.port
), it should show the following:
.:53
CoreDNS-1.6.6
linux/amd64, go1.13.5, aa8c32
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.
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 -dns.port
flag: coredns -dns.port 1053
, runs the server on port 1053.
Start a simple proxy. You'll need to be root to start listening on port 53.
Corefile
contains:
.:53 {
forward . 8.8.8.8:53
log
}
Start CoreDNS and then query on that port (53). The query should be forwarded to 8.8.8.8 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 example.org
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.
example.org:1053 {
file /var/lib/coredns/example.org.signed {
transfer to *
transfer to 2001:500:8f::53
}
errors
log
}
Serve example.org
on port 1053, but forward everything that does not match example.org
to a
recursive nameserver and rewrite ANY queries to HINFO.
example.org:1053 {
file /var/lib/coredns/example.org.signed {
transfer to *
transfer to 2001:500:8f::53
}
errors
log
}
. {
any
forward . 8.8.8.8:53
errors
log
}
IP addresses are also allowed. They are automatically converted to reverse zones:
10.0.0.0/24 {
whoami
}
Means you are authoritative for 0.0.10.in-addr.arpa.
.
This also works for IPv6 addresses. If for some reason you want to serve a zone named 10.0.0.0/24
add the closing dot: 10.0.0.0/24.
as this also stops the conversion.
This even works for CIDR (See RFC 1518 and 1519) addressing, i.e. 10.0.0.0/25
, CoreDNS will then
check if the in-addr
request falls in the correct range.
Listening on TLS (DoT) and for gRPC? Use:
tls://example.org grpc://example.org {
whoami
}
And for DNS over HTTP/2 (DoH) use:
https://example.org {
whoami
}
Specifying ports works in the same way:
grpc://example.org:1443 {
# ...
}
When no transport protocol is specified the default dns://
is assumed.
We're most active on Github (and Slack):
More resources can be found:
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.
When there is a backwards incompatible change in CoreDNS the following process is followed:
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.
A third party security audit was performed by Cure53, you can see the full report here.
If you find a security vulnerability or any security related issues, please DO NOT file a public
issue, instead send your report privately to security@coredns.io
. 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
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。