使用 CoreDNS 来应对 DNS 污染

CoreDNS 是新晋的 CNCF 孵化项目，前几天已经从 CNCF 正式结业，并正式成为 Kubernetes 的 DNS 处事器。CoreDNS 的方针是成为 cloud-native 情形下的 DNS 处事器和处事发明办理方案，即：

Our goal is to make CoreDNS the cloud-native DNS server and service discovery solution.

它有以下几个特征：

• 插件化(Plugins)

基于 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 名目如下所示：

ZONE:[PORT] { 
    [PLUGIN] ... 
} 

• ZONE : 界说 server 认真的 zone，PORT 是可选项，默以为 53;
• PLUGIN : 界说 server 所要加载的 plugin。每个 plugin 可以有多个参数;

好比：

 { 
chaos CoreDNS-001 
} 

上述设置文件表达的是：server 认真根域 . 的理会，个中 plugin 是 chaos 且没有参数。

界说 server

一个最简朴的设置文件可觉得：

.{}  

即 server 监听 53 端口并不行使插件。假云云时在界说其他 server，要担保监听端口不斗嘴;假如是在原本 server 增进 zone，则要担保 zone 之间不斗嘴，如：

. {} 
.:54 {} 

另一个 server 运行于 54 端口并认真根域 . 的理会。

又如：

example.org { 
    whoami 
} 
org { 
    whoami 
} 

统一个 server 可是认真差异 zone 的理会，有差异插件链。

界说 Reverse Zone

跟其他 DNS 处事器相同，Corefile 也可以界说 Reverse Zone(反向理会 IP 地点对应的域名)：

0.0.10.in-addr.arpa { 
whoami  
} 

可能简化版本：

10.0.0.0/24 { 
    whoami 
} 

可以通过 dig 举办反向查询：

$ dig -x 10.0.0.1 

行使差异的通讯协议

CoreDNS 除了支持 DNS 协议，也支持 TLS 和 gRPC，即 DNS-over-TLS 和 DNS-over-gRPC 模式：

tls://example.org:1443 { 
#... 
} 

2. 插件的事变模式

当 CoreDNS 启动后，它将按照设置文件启动差异 server ，每台 server 都拥有本身的插件链。当有 DNS 哀求时，它将依次经验如下 3 步逻辑：

假若有当前哀求的 server 有多个 zone，将回收贪婪原则选择最匹配的 zone;

一旦找到匹配的 server，凭证 plugin.cfg 界说的次序执行插件链上的插件;

每个插件将判定当前哀求是否应该处理赏罚，将有以下几种也许：

• 哀求被当前插件处理赏罚

插件将天生对应的相应并回给客户端，此时哀求竣事，下一个插件将不会被挪用，如 whoami 插件;

• 哀求被当前插件以 Fallthrough 情势处理赏罚

假如哀求在该插件处理赏罚进程中有也许将跳转至下一个插件，该进程称为 fallthrough，并以要害字 fallthrough 来抉择是否应承此项操纵，譬喻 host 插件，当查询域名未位于 /etc/hosts，则挪用下一个插件;

• 哀求在处理赏罚进程被携带 Hint

哀求被插件处理赏罚，并在其相应中添加了某些信息(hint)后继承交由下一个插件处理赏罚。这些特另外信息将构成对客户端的最终相应，如 metric 插件;

3. CoreDNS 如那里理赏罚 DNS 哀求

假如 Corefile 为：

coredns.io:5300 { 
    file db.coredns.io 
} 
 
example.io:53 { 
    log 
    errors 
    file db.example.io 
} 
 
example.net:53 { 
    file db.example.net 
} 
 
.:53 { 
    kubernetes 
    proxy . 8.8.8.8 
    log 
    health 
    errors 
    cache 
} 

（编辑：河北网）

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