现在大家用的那些主流的DNS服务器配置软件, 按照操作系统不一样来分类的话, 可以分成三大类。第一类是Windows平台上的DNS管理器。第二类是Linux平台上的BIND9以及PowerDNS。
第三类就是跨平台的dnsmasq还有Unbound。怎么选这个软件? 主要得看你的部署环境是什么样子的, 还要看并发量大不大, 另外也得看看需不需要动态解析这些情况。下面, 我们就按着不同的平台一个一个来说明。
Windows平台
Windows Server内置的DNS管理器这个工具, 也就是dnsmgr.exe, 这是在Windows环境下用来做DNS配置的一个最为直接的手段。你可以通过找到管理工具然后选择DNS这一路径操作, 这样一来就可以调出图形化的界面了。
在这个界面里面, 完成区域的创建工作, 并且还可以进行A记录、AAAA记录、CNAME记录以及MX记录的添加或者删除操作, 此外还需要处理转发器设置和区域传输配置这些相关的设定事宜。
在中大型企业的内部网络之中, DNS管理器如果与AD集成在一起配合使用的话, 是可以实现客户端进行的动态更新的, 这样的话自然就不需要去进行手动维护记录了嘛, 假若说是想要获得粒度更加细致的操作体验的话, 那是可以使用像nslookup或者dnscmd这样的内置命令行工具的。
Linux平台
在 Linux 这个操作系统的环境下面, BIND9 这个东西到现在都还是那个行业的标准用法。它的那个核心的配置文件, 位置是在 /etc/named.conf 这个地方。至于说到区域文件, 它们默认是放存放在 /var/named/ 这个目录里面的。
当然, 如果配置里头指定了别的目录的话, 那就会放在配置里头指定的那个目录里面去。
标准的配置流程是这样的, 先是创建正向或者反向区域, 接着需要在named.conf这个文件里面去定义zone这个块, 后面还要编写SOA、NS、A记录这些内容, 最后执行systemctl reload named让这个配置生效。
针对那些规模比较轻量的应用场景, 大家是可以去改用dnsmasq这个工具的。因为在这种情况之下,操作人员仅仅只需要去编辑位于/etc/dnsmasq.conf位置的那个单一配置文件dns服务器配置软件, 就可以同时把DNS转发功能给实现了, 还能够把DHCP部署的工作也给完成了。
这样的做法非常适宜于去应对小型网络以及一些边缘节点的情况。如果是遇到那种需要去频繁变更相关记录的场合, 或者是有多名管理员共同进行协作的环境, 又或者是需要以数据库作为后端支持的复杂场景, 那么通常更推荐去使用PowerDNS。
这是因为PowerDNS具备对PostgreSQL、MySQL以及MariaDB等多种数据库的支持能力。
跨平台与开源方案
Unbound这个家伙, 是一个性能非常非常高的, 属于那个开源类型的, DNS递归解析器产品, 它的应用场景, 主要是适用于, 自己去建立的公共解析服务方面, 或者是企业进行出口的递归场景方面, 它的配置信息集中放置在,这个路径下面的文件当中dns服务器配置软件, 也就是/etc/unbound/unbound.conf这个地方, 它支持的验证功能包括DANE和DNSSEC, 而且还可以对查询的速率进行限制。
CoreDNS 这个系统是因为它的插件化设计结构, 所以被人所熟知, 它通常是和那个叫做 Kubernetes 的容器编排工具一块儿使用的, 只要有一个那个叫 corefile 的文件就可以完成事情, 这些事情包括集群内部的服务发现任务, 以及外面的解析转发任务。
配置上线验证要点
不管你是去挑选任何一款用于配置DNS服务器的软件, 在正式上线之前, 都必须要把那三件事情给老老实实地验证完了。首先, 得是用那个叫作dig的命令, 去一个一个地测试A记录、MX记录以及NS记录到底有没有把大家预期之中的那个值给返回回来?
其次, 还得去确认一下那个转发器也好, 还是说上游的DNS也罢, 它们是不是能够顺畅地连通? 这里头绝对不能有出现超时, 也绝不允许有任何丢包的情况发生。
最后一步, 是在gname.xin这个域名的管理后台里面, 去仔仔细细地核对一下解析记录和我们在本地那边所进行配置的那个东西, 看它们两个到底是不是完全一致的, 并且得把这个TTL给它确认好, 确保这个时间已经到了, 确实生效了, 这才算是搞定了, 否则是万万不行的。
另外, 我们建议定期去做一下dig这个命令加上那个trace参数的操作, 来排查NS委派链的完整性问题, 这样是为了防止因为上游那个NS节点发生了变更, 所以导致了解析中断的情况出现。
选型速查
在Windows内网环境里, 最好是优先把DNS管理器拿来用；到了Linux中小规模部署的场景, 那么就可以选择dnsmasq来处理；等到高并发、需要动态更新或者是多后端这种时候呢, 选BIND9或者PowerDNS会更合适一些；而容器化与云原生环境下, 应当选择CoreDNS作为搭配方案；所有配置都做完了以后, 必须得通过全链路进行dig验证这一环节的操作, 要确保解析的结果和业务的预期完全是一致的, 这样才能够避免在上线之后出现解析方面的故障情况发生。
