CoreDNS是一个CNCF下的孵化级项目，它的前身是SkyDNS，主要目的是构建一个快速灵活的DNS服务器，让用户可以通过不同方式访问和使用DNS内的数据。CoreDNS基于Caddy服务器框架，实现了一个插件链的架构，将大量逻辑抽象成插件的形式暴露给使用者，每个插件都执行DNS功能，例如Kubernetes的DNS服务发现、Prometheus监控等。
除了插件化之外，CoreDNS还有以下特性：
·配置简单化：引入表达力更强的DSL，即Coref ile形式的配置文件（也是基于Caddy框架开发）。
·一体化的解决方案：与kube-dns不同，CoreDNS编译出来就是一个单独的二进制可执行文件，内置了cache、backend storage、health check等功能，无需第三方组件来辅助实现其他功能，从而使部署更方便，内存管理更为安全。
Coref ile是CoreDNS的配置文件（源于Caddy框架的配置文件Caddyf ile），定义了如下信息：
·服务器以什么协议监听在哪个端口（可以同时定义多个server监听不同端口）。
·服务器负责哪个zone的authoritative DNS解析。
·服务器将加载哪些插件。
典型的Coref ile格式如下所示：
ZONE:[PORT] {
[PLUGIN] ...
}
其中：
·ZONE：用于定义服务器负责的zone。
·PORT：监听端口，可选项，默认为53。
·PLUGIN：定义服务器所要加载的插件，每个插件可以有多个参数。
了解了CoreDNS上述介绍之后，接下来让我们一起了解一下它的插件工作机制。
当CoreDNS启动后，插件将根据配置文件启动不同的server，每台server都拥有自己的插件链。当有DNS请求时，插件将依次执行如下步骤：
1）如果当前请求的server有多个zone，将采用贪心原则选择最配的zone。
2）一旦找到匹配的server，按照plugin.cfg定义的顺序执行插件链上的插件。
3）每个插件将判断当前请求是否应该处理，有以下几种可能：
·请求被当前插件处理：插件将生成对应的响应并回给客户端，此时请求结束，下一个插件将不会被调用，如whoami插件。
·请求不被当前插件处理：直接调用下一个插件。如果最后一个插件执行错误，服务器返回SERVFAIL响应。
·请求被当前插件以Fallthrough形式处理：如果请求在该插件处理过程中有可能将跳转至下一个插件，该过程称为fallthrough，并以关键字fallthrough来决定是否允许此项操作，例如host插件，当查询域名未位于/etc/hosts，则调用下一个插件。
·请求在处理过程中携带信息：请求被插件处理，并在其响应中添加了某些信息（hint）后继续交由下一个插件处理。这些额外的信息将组成对客户端的最终响应，如metric插件。