灵活可扩展的DNS服务组件，提供集群内的服务发现与域名解析能力
CoreDNS 是一款采用 Go 语言编写的 DNS 服务器/转发器，它通过插件形成链式处理流程。每个插件负责执行一项（DNS）功能。
CoreDNS 是云原生计算基金会（Cloud Native Computing Foundation）的毕业项目。
CoreDNS 是一款快速且灵活的 DNS 服务器。这里的关键词是“灵活”：借助 CoreDNS，您可以通过使用插件对 DNS 数据进行任意操作。如果某些功能未开箱即提供，您可以通过编写插件来添加。
CoreDNS 能够监听通过以下方式传入的 DNS 请求：
- UDP/TCP（传统 DNS）。
- TLS - DoT（DNS over TLS，RFC 7858）。
- DNS over HTTP/2 - DoH（DNS over HTTPS，RFC 8484）。
- DNS over QUIC - DoQ（DNS over QUIC，RFC 9250）。
- gRPC（非标准协议）。
目前，CoreDNS 能够：
- 从文件提供区域数据；同时支持 DNSSEC（仅 NSEC）和 DNS（file 和 auto 插件）。
- 从主服务器获取区域数据，即充当辅助服务器（仅支持 AXFR）（secondary 插件）。
- 动态签名区域数据（dnssec 插件）。
- 对响应进行负载均衡（loadbalance 插件）。
- 允许区域传输，即充当主服务器（file + transfer 插件）。
- 自动从磁盘加载区域文件（auto 插件）。
- 缓存 DNS 响应（cache 插件）。
- 使用 etcd 作为后端（替代 SkyDNS）（etcd 插件）。
- 使用 k8s（Kubernetes）作为后端（kubernetes 插件）。
- 作为代理将查询转发到其他（递归）名称服务器（forward 插件）。
- 提供指标（通过使用 Prometheus）（prometheus 插件）。
- 提供查询（log 插件）和错误（errors 插件）日志记录。
- 与云服务提供商集成（route53 插件）。
- 支持 CH 类：
version.bind及类似记录（chaos 插件）。 - 支持 RFC 5001 DNS 名称服务器标识符（NSID）选项（nsid 插件）。
- 支持性能分析（pprof 插件）。
- 重写查询（查询类型、查询类别和查询名称）（rewrite 和 template 插件）。
- 阻止 ANY 查询（any 插件）。
- 提供 DNS64 IPv6 转换（dns64 插件）。
以及更多功能。每个插件都有相应文档。所有内置插件请参见 coredns.io/plugins，所有外部插件请参见 coredns.io/explugins。
从源代码编译
要编译 CoreDNS，我们假设您已配置好可用的 Go 开发环境。如果尚未配置，请参考相关教程进行设置。
首先，请确保您的 golang 版本为 1.23.0 或更高，因为需要支持 go mod 及其他相关 API。有关 go mod 的详细信息，请参见 此处。
然后，检出项目并运行 make 命令来编译二进制文件：
$ git clone https://github.com/coredns/coredns
$ cd coredns
$ make
注意： 构建时，可以通过设置
COREDNS_PLUGINS环境变量来启用额外插件，该变量的值为用逗号分隔的插件列表，格式需与 plugin.cfg 中的一致。
此操作将生成一个 coredns 二进制文件。
使用 Docker 编译
CoreDNS 需要 Go 环境进行编译。不过，如果你已安装 Docker 且不想搭建 Go 环境，也可以轻松构建 CoreDNS：
docker run --rm -i -t \
-v $PWD:/go/src/github.com/coredns/coredns -w /go/src/github.com/coredns/coredns \
golang:1.22 sh -c 'GOFLAGS="-buildvcs=false" make gen && GOFLAGS="-buildvcs=false" make'
仅上述命令即可生成 coredns 二进制文件。
示例
在未进行任何配置的情况下启动 CoreDNS 时，它会加载 whoami 和 log 插件，并开始在 53 端口监听（可通过 -dns.port 覆盖默认端口），此时应显示以下内容：
.:53
CoreDNS-1.6.6
linux/amd64, go1.16.10, aa8c32
以下命令可用于查询当前运行的 CoreDNS 服务器：
dig @127.0.0.1 -p 53 www.example.com
发送至端口 53 的任何查询都应返回一些信息，包括您的发送地址、端口以及所使用的协议。该查询还应记录到标准输出中。
CoreDNS 的配置通过名为 Corefile 的文件完成。CoreDNS 启动时，会从当前工作目录中查找 Corefile。以下是一个 CoreDNS 服务器的 Corefile 示例，该服务器监听端口 53 并启用 whoami 插件：
.:53 {
whoami
}
有时 53 端口会被系统进程占用。这种情况下，你可以通过如下方式修改 Corefile，让 CoreDNS 服务器在 1053 端口启动。
.:1053 {
whoami
}
如果您的 Corefile 中未指定端口号，默认情况下将使用 53 端口，但您可以通过 -dns.port 标志覆盖该端口：coredns -dns.port 1053 会使服务器在 1053 端口上运行。
您可以使用 import 指令将其他文本文件导入到 Corefile 中。您可以使用通配符通过单个 import 指令匹配多个文件。
.:53 {
import example1.txt
}
import example2.txt
你可以在 Corefile 中使用 {$VARIABLE} 形式的环境变量。请注意，每个环境变量都将作为单个标记插入到 Corefile 中。例如，包含空格的环境变量将被视为单个标记，而非两个独立的标记。
.:53 {
{$ENV_VAR}
}
一个将所有查询转发到上游DNS（例如 8.8.8.8）的 CoreDNS 服务器的 Corefile 如下：
.:53 {
forward . 8.8.8.8:53
log
}
启动 CoreDNS，然后在 53 端口上进行查询。查询将被转发至 8.8.8.8，并返回响应。每个查询也会显示在标准输出的日志中。
要在 1053 端口提供（NSEC）DNSSEC 签名的 example.org 区域，错误和日志将发送至标准输出。允许所有人进行区域传输，但需明确指定一个 IP 地址，以便 CoreDNS 能向其发送通知。
example.org:1053 {
file /var/lib/coredns/example.org.signed
transfer {
to * 2001:500:8f::53
}
errors
log
}
在 1053 端口上提供 example.org 服务，但将所有与 example.org 不匹配的请求转发到递归名称服务器，同时将 ANY 查询重写为 HINFO。
example.org:1053 {
file /var/lib/coredns/example.org.signed
transfer {
to * 2001:500:8f::53
}
errors
log
}
. {
any
forward . 8.8.8.8:53
errors
log
}
也允许使用 IP 地址。它们会自动转换为反向区域：
10.0.0.0/24 {
whoami
}
这意味着您对 0.0.10.in-addr.arpa. 具有权威性。
这同样适用于 IPv6 地址。如果出于某种原因您想提供名为 10.0.0.0/24 的区域，请添加末尾的点：10.0.0.0/24.，这样也能阻止转换。
这甚至适用于 CIDR（参见 RFC 1518 和 1519）寻址，例如 10.0.0.0/25，CoreDNS 随后会检查 in-addr 请求是否落在正确的范围内。
要监听 TLS（DoT）和 gRPC？请使用：
tls://example.org grpc://example.org {
whoami
}
类似地，对于 QUIC（DoQ）：
quic://example.org {
whoami
tls mycert mykey
}
而对于基于 HTTP/2 的 DNS（DoH），请使用：
https://example.org {
whoami
tls mycert mykey
}
在此设置中，CoreDNS 将负责 TLS 终止。
你也可以启动 DNS 服务器以 DoH 模式运行，且不进行 TLS 终止（即纯 HTTP），但请注意，在此场景下，CoreDNS 实例前必须部署某种 TLS 终止代理，由该代理转发 DNS 请求，否则客户端将无法通过 DoH 与服务器进行通信。
https://example.org {
whoami
}
指定端口的方式相同：
grpc://example.org:1443 https://example.org:1444 {
# ...
}
如果未指定传输协议，则默认使用 dns://。
社区
我们在 GitHub（和 Slack）上最为活跃：
- GitHub：https://github.com/coredns/coredns
- Slack：https://slack.cncf.io 上的 #coredns 频道
更多资源可参考：
- 网站：https://coredns.io
- 博客：https://coredns.io/blog/
- 推特：@corednsio
- 邮件列表/群组：coredns-discuss@googlegroups.com（不太活跃）
贡献指南
如果您想为 CoreDNS 做贡献，请务必查看 贡献指南。
部署
有关通过 systemd 部署的示例以及其他使用场景，可在 部署仓库 中找到。
弃用政策
当 CoreDNS 中出现不向后兼容的变更时，将遵循以下流程：
- 版本 x.y.z：宣布在下一个版本中我们将进行向后不兼容的变更。
- 版本 x.y+1.0：增加次要版本号，并将补丁版本号设为 0。实施变更，但允许解析旧配置。即 CoreDNS 可以从未更改的 Corefile 启动。
- 版本 x.y+1.1：将补丁版本号增加到 1。移除宽松解析，因此如果仍在使用这些功能，CoreDNS 将无法启动。
例如：1.3.1 版本宣布一项变更。1.4.0 版本是包含该变更但配置向后兼容的新版本。最后，1.4.1 版本将移除配置兼容的相关处理。
安全
安全审计
第三方安全审计由以下机构执行：
- Cure53 于 2018 年 3 月。完整报告
- Trail of Bits 于 2022 年 3 月。完整报告
报告安全漏洞
如果您发现安全漏洞或任何与安全相关的问题，请不要提交公开 issue，而是将报告私下发送至 security@coredns.io。我们非常感谢安全报告，并会公开感谢您的贡献。
请参考 安全漏洞披露以及安全修复和发布流程文档。