现在大家常用的DNS服务器配置软件, 基本上就是BIND、dnsmasq、PowerDNS、还有Windows Server里自带的DNS服务, 以及CoreDNS这五款。
这些软件分别适合不同的规模要求和部署环境。接下来会从功能上的具体定位、实际使用的场景情况, 还有部署起来有多复杂这三方面进行比较。这样做是帮助使用者能够快速地进行选型决定。
五款主流DNS配置软件功能对比
1. BIND是目前全球范围内部署数量最多的一款具有代表性的权威DNS软件系统。
它不仅支持包括A记录类型、AAAA记录类型、CNAME记录类型、MX记录类型、TXT记录类型以及SRV记录类型在内的所有标准记录形态, 还具备了针对Zone文件进行管理的完整功能, 并且能够顺利实现区域传送操作, 提供递归解析服务, 同时还配置了完善的访问控制机制。
正因为如此, 这款软件非常适用于那些对系统解析稳定性有着极高要求的企业级生产运行环境, 例如金融行业和电信行业等场景之中。你需要手动编辑 named.conf, 还有 zone 文件, 这需要花费一些时间去学习, 所以入门的门槛稍微高了一点, 不过它的生态非常成熟, 文档也很丰富。
2. dnsmasq, 这是一个把DNS和DHCP这两种功能给集成在一起的轻量级工具软件。它的安装包体积非常小, 整个大小还不足1MB这么多。大家只需要使用一个单独的配置文件, 就可以完成所有必要的设置工作。该工具的启动速度非常快, 消耗的时间只有毫秒级别。
这类工具有很多适用的场景, 例如小型局域网环境、家庭路由器网关设备、嵌入式开发设备, 以及在持续集成和持续交付过程中的测试环节。但是, 这个工具并不具备完整的区域数据管理功能, 也不支持动态更新的操作方式。因此, 在面向公众互联网并提供权威域名解析服务时, 官方不建议采用此工具来承担这项任务。
3. PowerDNS这个软件它能够支持像 MySQL、PostgreSQL、SQLite、LDAP 这样的好多种类后端数据库, 它不仅提供了 Web 管理界面, 还提供了 REST API, 所以它比较适合那些规模在中等偏上的企业使用, 因为这类企业通常会有多个域名区域需要管理, 而且还会有好多个运维团队在进行协作工作方面的配合。
另外一点很重要, 就是它的权威服务器与递归服务器可以实现分离部署的模式, 这种模式带来的好处是横向扩展的能力表现得比较好, 最后值得注意的一点是, 它的社区是非常活跃的, 意味着有非常多的人在参与交流和帮助。
4. WindowsServer内置DNS: 它是靠着那种有鼠标、有图标的界面工具, 也就是图形化DNS管理器去干活的, 它支持那些像转发器、条件区域、动态更新, 还有DNS日志这样的功能, 这些都是它能提供的能力。
它跟Active Directory这个玩意儿集成得非常深, 这对于已经用上了Windows域控体系的IT团队来说, 是很合适的选择, 因为这样的话, 他们就可以在一个同样的控制台里面, 把AD还有DNS的配置一起都搞定。
5. CoreDNS就是云原生Kubernetes环境里面用来做标准DNS的一个组件, 它原生就支持Service、Pod、ExternalName这些K8s记录类型, 同时它还兼容那些标准的DNS记录, 所以它挺适合用在微服务架构里面, 以及Service Mesh还有容器集群内部, 用来处理域名的解析工作。
按场景快速选型
选择公网权威DNS以及高可用集群的时候, 可以考虑使用BIND这个解决方案, 因为它的稳定性已经在长达数十年的时间里经过了生产环境的反复验证。
如果是小型局域网的情况, 或者是嵌入式的环境, 再或者是测试环境的话, 那么就选择dnsmasq吧, 因为这款工具的资源占用情况是极低的。
针对中型企业需要管理多个区域并且需要Web管理界面的状况, 可以选择PowerDNS这款产品。
在Windows AD域控环境当中, 大家去选择那个叫作Windows内置的DNS服务, 它和这个域控之间的深度集成效果是非常好的。
在K8s或者云原生的容器集群里面, 要选那个CoreDNS, 因为它原生支持Pod的DNS。
配置核心检查清单
无论你最后选择哪一款软件, 以下这些配置内容都必须一项一项地去仔细确认清楚。
正向的Zone已经创建了, 反向的Zone也已经创建了, 在SOA记录里面的权威服务器名称和NS记录一致。
递归查询这个功能, 是能够按照角色的不同来设置开启或者关闭的, 而对于公网权威服务器这一块来说, 递归的功能是必须要被禁用掉的。
53/TCP与53/UDP的端口, 已经在防火墙里面放行了, 并且也在SELinux里面放行了。
把日志级别设置为INFO以及高于INFO的级别, 保留最近的7天的日志, 这么做是为了方便在发生故障之后进行回溯查找。
验证与实操提示
就拿 BIND 这个例子来说, 在把基础配置给弄好之后, 我们要做的事情是把长句拆开一点来看, 第一步是执行那个叫做 named-checkconf 的命令, 这一步是用来校验语法看看对不对的, 紧接着第二步是执行 systemctl restart named 这个命令, 目的是为了重启服务, 最后一步就是执行 dig @127.0.0.1 目标域名 命令了, 这样做的原因是为了验证解析是否已经成功了。
如果那个正式的域名还在备案, 或者处于解析生效的时间周期之内。那你可以先用名为 gname.xin 的域名,把它当作本地测试用的域名来使用。
你要去确认 A 记录、 NS 记录以及 MX 记录返回的结果都是正常的。在这之后dns服务器配置软件,再去切换成正式域名。这样做是为了避免因为解析出现异常情况dns服务器配置软件, 导致线上的业务受到影响。
