CoreDNS 来应对 DNS 污染

 Caddy 服务器框架，CoreDNS 实现了一个插件链的架构，将大量应用端的逻辑抽象成 plugin 的形式(如 Kubernetes 的 DNS 服务发现，Prometheus 监控等)暴露给使用者。CoreDNS 以预配置的方式将不同的 plugin 串成一条链，按序执行 plugin 的逻辑。从编译层面，用户选择所需的 plugin 编译到最终的可执行文件中，使得运行效率更高。CoreDNS 采用 Go 编写，所以从具体代码层面来看，每个 plugin 其实都是实现了其定义的 interface 的组件而已。第三方只要按照 CoreDNS Plugin API 去编写自定义插件，就可以很方便地集成于 CoreDNS。

• 配置简单化

引入表达力更强的 DSL，即 Corefile 形式的配置文件(也是基于 Caddy 框架开发)。

• 一体化的解决方案

区别于 kube-dns，CoreDNS 编译出来就是一个单独的二进制可执行文件，内置了 cache，backend storage，health check 等功能，无需第三方组件来辅助实现其他功能，从而使得部署更方便，内存管理更为安全。

其实从功能角度来看，CoreDNS 更像是一个通用 DNS 方案(类似于 BIND)，然后通过插件模式来极大地扩展自身功能，从而可以适用于不同的场景(比如 Kubernetes)。正如官方博客所说：

CoreDNS is powered by plugins.

1. Corefile 介绍

Corefile 是 CoreDNS 的配置文件(源于 Caddy 框架的配置文件 Caddyfile)，它定义了：

server 以什么协议监听在哪个端口(可以同时定义多个 server 监听不同端口)

server 负责哪个 zone 的权威(authoritative)DNS 解析

server 将加载哪些插件

常见地，一个典型的 Corefile 格式如下所示：DNS 请求时，它将依次经历如下 3 步逻辑：

如果有当前请求的 server 有多个 zone，将采用贪心原则选择最匹配的 zone;

一旦找到匹配的 server，按照 plugin.cfg 定义的顺序执行插件链上的插件;

每个插件将判断当前请求是否应该处理，将有以下几种可能：

• 请求被当前插件处理

插件将生成对应的响应并回给客户端，此时请求结束，下一个插件将不会被调用，如 whoami 插件;

• 请求被当前插件以 Fallthrough 形式处理

如果请求在该插件处理过程中有可能将跳转至下一个插件，该过程称为 fallthrough，并以关键字 fallthrough 来决定是否允许此项操作，例如 host 插件，当查询域名未位于 /etc/hosts，则调用下一个插件;

• 请求在处理过程被携带 Hint

请求被插件处理，并在其响应中添加了某些信息(hint)后继续交由下一个插件处理。这些额外的信息将组成对客户端的最终响应，如 metric 插件;

（编辑：开发网_郴州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!