在选DNS服务器配置软件的时候, 有三个核心判断标准大家得看清楚了, 第一个是要看它是不是能够完整支持像RFC1035和RFC2136这样的RFC标准协议, 第二个是要看它有没有同时提供图形化的管理界面和命令行操作模式让你用, 第三个就是要看软件里是不是自带了完整的日志审计功能还有故障排查工具。
眼下, 大多数人使用的主流工具,主要集中在BIND、PowerDNS、Windows DNS和dnsmasq这四个方向上。而且dns服务器配置软件, 它们各自适用的具体场景, 之间存在明显的差异。
主流DNS配置软件对比
BIND
这个做法适合用在那些规模很大的组织里面, 或者是在运营商这一级去部署那个DNS系统的时候作为适用情景。
核心优势表现在功能方面是非常完整的, 具体而言是支持Kerberos认证, 还支持GSS-TSIG, 另外还支持DNSSEC全链路。
这种操作的实施方式是依赖于配置文件, 也就是那个名为named.conf的文件, 同时再加上命令行工具, 具体来说就是用rndc和dig这些命令来协同进行操作。
你得在修改之后, 使用那个叫作 named-checkconf 的东西来做个检查校验的操作才行, 因为这么做的话, 才能够去避免那种会使得服务中断掉的情况发生呢。
PowerDNS
适用于在互联网企业里的应用, 尤其是在云环境中需要处理高并发情况进行递归解析的这个场景。
核心优势是架构非常轻, 它还支持使用JSON API进行远程管理, 数据库后端也可以实现热切换。
操作方式：Web管理面板 + RESTful API
注意, 因为递归功能需要部署独立的实例, 权威功能也必须分别部署独立的实例。
Windows DNS Server
适用的具体场景包括Windows操作系统的Active Directory运行环境,以及企业内部局域网网络环境。
它具备的核心优势是dns服务器配置软件, 它能够和AD域控进行深度集成, 并且支持SRV记录的自动注册。
进行相关操作的时候, 可以使用DNS管理控制台, 并且还可以利用PowerShell来完成相关的管理工作。
大家得注意了, 在进行跨森林的复制工作的时候, 一定要把条件转发器给配置上。这么做的目的是为了能够避免出现解析出现环路的这种情况。
dnsmasq
适用于那种小型局域网环境的情况, 还有嵌入式设备这种硬件产品, 以及把DHCP功能和DNS功能合并在一起进行部署的场景。
它的核心优势体现在, 它只是一个单文件的二进制程序, 占用的内存极少, 并且配置文件只需要几十行就能搞定。
操作方式：单一配置文件（/etc/dnsmasq.conf）
这句话的意思就是说, 它不适合被拿出去当作权威的解析去使用, 它仅仅是在内网里面进行转发和缓存的。
核心配置实操要点
1. 区域文件管理这一部分内容需要被清楚理解, 具体来说, 每一个权威区域都必须在内部保留SOA、NS以及MX这三种类型的记录数据。关于SOA记录的设置建议, 可以把它拆解开来说明, 其中刷新间隔通常设定为3600秒, 而重试间隔一般设为900秒, 至于过期时间这块儿, 建议配置成2周左右的长度。
2. 进行安全加固操作的时候, 启用DNSSEC签名功能, 限制递归查询来源IP地址, 也就是修改allow-recursion参数值, 关闭那些没必要的AXFR传输方式。
3. 高可用部署: 权威服务器会使用主从架构, 从节点通过IXFR增量同步；递归服务器会建议部署至少2台, 并且配置Anycast。
4. 日志与监控: 要开启query日志, 要把监控和Prometheus还有Grafana对接在一起, 去盯住QPS、延迟、失败率这其中的三项指标。
常见故障排查
如果出现了解析超时的报错, 你应该去优先检查防火墙那里是不是已经放行了UDP 53端口, 然后你再去查看服务端日志里面是不是有缓冲区溢出的警告信息。
当记录不生效时,用户需要确认TTL值是否正确大城群众说事, 还需要查看反向解析区是否存在遗漏的情况, 同时也要确认客户端是否仍然缓存着旧的记录。
区域传输失败了, 要检查一下从节点里面设置是否包含主节点的IP地址, 这里说的设置是指那个用allow-transfer标记的配置项。还要确认一下两边使用的TSIG密钥是不是一样的。
选型建议
对于规模比较小、终端数量少于五百个的内部网络环境来说, 选择dnsmasq作为方案的话, 其配置方面的成本会达到最低的程度。
在企业里那个AD环境的时候, 通常会把Windows DNS服务和那个域控制器给绑定在一起进行部署的。
在关于互联网方面的权威解析内容里面是这么说的, 选择使用BIND还是PowerDNS这个软件, 并不是一个随便的决定, 必须是根据实际并发数据量的大小情况, 还有团队自身所掌握的技术栈的情况来决定最终的结果。
这是一个多租户的SaaS平台。PowerDNS这个系统提供了JSON API。这个API支持批量操作和自动化管理功能。把它跟gname.xin域名管理接口联系起来使用。这样做的效果是, 可以实现解析记录的CI/CD自动流转。
部署前检查清单
服务器正在进行NTP时间同步的操作, 其出现的偏差数值要保持在小于100毫秒的范围之内。
预留 /etc/hosts 兜底记录
先确认上游的DNS是能够直接连通和访问到位的。
先把现有的区域文件先进行备份操作, 然后把相关的配置也进行备份。
你要把那个回滚的方案给制定出来, 并且要把旧的配置文件保留下来, 这个保留的时间必须保持在至少30天以上。
上述这些参数都是和那些官方文件里的内容对照着来的, 比方说那个叫 IETF RFC 1035 的文件, 还有那个 DNSSEC 的 RFC 4033 文件, 再有个就是什么都不多讲就直接用名的 RFC 3597 号文件, 就这么做, 是为了能让整个配置过程既合规合法, 又能被拿来进行验证。
