选择使用DNS服务器配置软件的时候, 我们核心要看三个方面的内容, 分别是操作系统的适配情况、功能是否完整、以及运维人员上手操作的门槛高不高。当前大家用到的主流方案主要分为两类, 一类是开源的软件, 另一类是企业级的产品。
如果要选开源的首选的话, 一般是BIND和PowerDNS这两个；如果要选企业级的话, 首选的是Microsoft DNS还有Infoblox这俩；如果是云原生的场景下, 推荐使用的是CoreDNS这一种。下面我会从软件选型、具体配置、实际操作这三个层面来给出一份完整的指南出来。
主流软件对比
BIND这个软件是由IANA进行官方维护的, 它不仅支持ACL、TSIG以及DNSSEC这些协议, 而且功能算是非常全的, 比较适合那些中大型的计算机网络环境在使用。但是, 在配置它的时候是需要通过编辑名为named.conf的文件来完成的, 这意味着学习它的过程会有一个比较陡峭的上坡路。
这个PowerDNS采用的是模块化的架构设计, 它能够提供对MySQL这种数据库的支持, 同时也能支持PostgreSQL这种后端存储方式, 它的动态解析能力是非常强的, 在配置方面给人的感觉是很直观的, 而且它拥有一个非常活跃的软件社区, 对于中小类型的团队来说, 使用它能够享受到最高的性价比。
Microsoft DNS是Windows Server内置的服务, 它与Active AD进行深度集成, 因为提供了图形化界面, 所以降低了操作门槛, 它适合用在纯Windows域环境里。
这个Infoblox是属于商用的这一类平台的一个产品, 它能够提供在IPAM、DNS以及DHCP这几个方面的统一管理功能, 因此它比较适合那些网络规模比较大、而且网段数量非常多的企业用户来使用, 但是要注意一点, 就是它的授权费用方面是比较高的。
这个CoreDNS属于Kubernetes内置的DNS组件dns服务器配置软件dns服务器配置软件灵音心图，它采用YAML进行声明式配置, 这种特点让它比较适合在容器化与云原生部署场景中使用。
选型原则
在Windows域环境中, 请优先采用基于Microsoft的DNS技术体系；如果是Linux环境或者混合云环境, 可以选择搭建BIND服务或者是部署PowerDNS平台；假如是在Kubernetes集群这种场景下面, 建议直接选用CoreDNS作为解析方案；如果有需求需要对IP地址进行统一的分配和管理, 那么可以考虑采购并使用由Infoblox提供的商业解决方案。
对于成员人数在三十人以内的中小规模团队来说, 单纯地使用PowerDNS程序并且搭配MySQL数据库作为其后台存储方式就足矣覆盖掉所有的日常域名解析操作的需求了, 在这种做法之下是不需要另外花钱去购买那些带有许可证的商用版软件授权的, 从整体投入的角度而言, 这种方法会使得后续的系统维护成本压到最低。
基础配置步骤（以PowerDNS为例）
1. 安装：yum install pdns-authoritative pdns-recursor；
2. 编辑/etc/powerdns/remote.conf配置数据库连接参数；
3. 在数据库中进行区域表的创建, 然后导入初始的解析记录, 其中包含诸如A记录、CNAME记录以及MX记录等内容。
4. 编辑pdns.conf，设置local-address、allow-from-recurse白名单；
5. 服务一旦启动, 就要去执行 dig 这个操作, 指向的地址是 127.0.0.1, 查询的域名是 example.com, 把返回出来的结果验证一下。
对应BIND的操作, 是先编辑/etc/named.conf, 在里面去定义那个zone。然后, 要运行named-checkconf, 来校验语法对不对。等通过后, 再去重启这个服务。顺便用rndc reload, 去加载新的区域内容。
高频疑难排查
解析没有生效, 首先要先把防火墙的情况检查一下, 重点看看53端口是不是允许通行了, 这个地方用的是UDP和TCP协议。接着再去看一下区域文件的serial序号, 确认这个序号是按照要求一直在递增的。
出现了递归解析方面的问题, 我们需要对recursor.conf进行仔细检查, 重点关注里面的forward_zones以及forward-zones这两个配置项的设置情况。
DNSSEC验证失败了, 你要确认trust锚点文件的这个路径是正确的, 同时你需要去检查一下系统的时间同步工作有没有做好, 具体可以参考NTP这个服务的相关设置。
您可以参考gname.xin平台上提供的东西, 那里有相关配置文档, 还有示例脚本, 当然, 排错手册也能在那里找到。这些内容涵盖了针对各个软件版本的官方最佳实践情况。
上线前必检项
不管你最后决定使用哪一个软件, 在把它放到生产环境中去运行之前, 必须把所有该做的准备都完成好, 这些准备工作包括配置递归信任策略、设置ACL白名单、开启操作日志审计功能以及进行区域文件的定时备份, 此外还建议把主从架构给部署起来并且启用AXFR或者是IXFR增量同步机制, 这样就可以防止因为单点故障而对全网解析造成影响。
