CoreDNS篇6-递归服务器
本文最后更新于:February 20, 2022 pm
本文主要用于介绍CoreDNS实现递归服务器的几种方式以及在生产环境中遇到的一些问题和解决方案。
在开始之前我们需要知道一些关于CoreDNS的基本知识:CoreDNS本身是没有能力作为一个递归查询的DNS服务器(Recursive DNS),但是它有着众多的插件,可以通过插件来实现对域名的递归查询和缓存等功能从而加速客户端的DNS查询性能。这里主要实现的插件有内部插件(Plugins)forward
或外部插件(External Plugins)unbound
。
CoreDNS官方对External Plugins的描述为:
Out of tree plugins for CoreDNS. A plugin listed here is not automatically endorsed by the CoreDNS team. Issues should be reported to owner(s) of the plugin.
我们可以将CoreDNS的External Plugins简单理解为第三方插件,但是其中少部分会有官方的维护支持或者是直接默认内置在官方编译好的版本中。
1、unbound
我们先来了解一下不依靠外部程序实现递归查询功能的unbound插件,unbound是一个非常优秀的DNS软件,专注于递归查询和缓存,但对于权威DNS服务器这方面的功能稍显不足,因此理论上将unbound和CoreDNS结合就可以很好的弥补两者的不足。
1.1 编译安装
unbound插件的编译安装稍显麻烦,此前的文章中有详细介绍操作步骤和注意事项,需要特别注意的是编译安装了unbound
插件的CoreDNS会从原来的静态二进制文件,变成了需要动态加载依赖库。因此如果需要提前编译然后大范围使用,最好保证编译环境的系统和最终的使用环境系统一致或全兼容。
1.2 一些问题
unbound插件已经很长一段时间没有更新维护了,尽管它有Maintained by CoreDNS
的标注,因此如果使用较新版本的go编译之后,在启动的时候会有报警。
1 |
|
另外就是在运行的过程中会出现panic异常,一开始怀疑是和负载有关,后面测试发现当请求量极低(个位数qps)的时候也会出现此类异常。
1 |
|
经过多次测试之后,我们发现针对unbound插件出现panic
的情况和请求的频率无关,而是和请求的内容有关。简单来说就是:当请求的域名本身就不存在解析的时候,就会触发panic异常;当然还可以再进一步:当CoreDNS服务端本身无法和根域名服务器建立连接转发查询的时候,也会出现panic异常。
2、forward
2.1 配置使用
forward插件主要的作用就是把DNS请求转发给上游的upstream服务器。forward
插件本身并不支持任何的DNS解析功能,但是可以将相应的请求转发到递归服务器上,再结合cache
插件做缓存,从而实现递归查询解析缓存的功能。
1 |
|
forward对应的upstream机器可以根据自己的需求选择现有的公共DNS,如国内常见的114、谷歌的8888等免费DNS,或者选择自己使用unbound、bind9之类的DNS服务器单独搭建一个专门用来做递归查询的DNS服务。
2.2 一些问题
1 |
|
当查询的域名解析记录不存在或者是网络问题不可达的时候,可能会触发upstream的超时时间限制,导致报错i/o timeout
,可以考虑使用error
插件的consolidate
指令对这类报警进行统一处理并修改报警等级
1 |
|