DNS 这个东西，可大可小，可简单可复杂。对于以园区网为主的传统企业 / 单位而言，要考虑多出口的链路优化、智能解析、私有域名的解析 、监控、管理等一系列问题，还是需要有一个好的设计优化的。

　　通常一个园区网都会有多个出口。我们需要通过路由策略来决定用户的请求最终落入哪个出口上。在网络层上，BGP 自然不必多说了，静态路由的话，我们也可以设法去弄到各个运营商的地址表（万能的淘宝）然后写入路由，从而让用户的请求落入最合理的出口链路上。

　　“让用户的请求落入最合理的出口链路上”，靠路由表就够了吗？非也，因为还有 CDN。很自然地，由于有 CDN ，大部分网站的所提供的解析，都会根据用户的 DNS 请求来源，而智能解析到对应运营商区域内的 CDN 上。

　　也就是说，实际上我们 DNS 递归时的网络路由策略，基本决定了用户访问网站的实际路由。例如我们的 DNS 通过电信的链路去递归解析，那么用户解析到的网站地址多半也会落在该网站的电信 CDN 上，因此最终的请求也将被路由至电信链路上。

　　现在的问题在于，不同网站，在不同链路的 CDN 上的访问体验是不一致的！举个例子，QQ 邮箱（，如果他落在教科网的 CDN 上，附件经常就传不上去。12306 在电信的 CDN 问很快，而在教科网的 CDN 上就经常卡的飞起。说到底这其实就是不同链路之间的质量差异，毕竟价格也要差好多呢。

　　把默认路由全都给质量最好的链路就行了呗？理想很丰满，但是小钱钱很骨干呐！实际上我们拥有的链路带宽大小通常也与链路质量成反比。因此我们需要在用户的访问体验和链路的带宽利用率上寻找一个平衡。

　　如同 CDN 一般。我们自己也有多条出口，因此我们自己的服务在提供 DNS 解析的时候，也得根据用户解析的请求地址，来进行智能的解析，来提高我们网站的外部访问速率。

　　在我们的数据中心里，我们会需要一些私有的域名分配给服务器。这样会方便管理，也可以利用 DNS 做一些服务注册的工作。所以我们要有私有的域名，但是需要限制在数据中心之内，避免园区内的普通用户能够直接解析到。

　　刚才我们提到了服务注册。实际上无论是从运维自动化来考虑还是流程自动化来考虑，我们都需要 DNS 对应的 API 接口，能够让我们自动化的注册、修改、删除域名。

　　如同我们所有的服务一样，DNS 我们也需要有对应的服务监控。这需要我们的 DNS 本身能够暴露出相应的状态接口，提供服务状态的查询方法。我们通过脚本等去采集状态信息推送给监控系统（Open-Falcon）。

　　我们需要一个方便易用的前端来做 DNS 的域名管理。需要能够进行权限的控制，给不同的域分配不同的管理员。能够记录每次变更的操作记录。彻底结束 SSH 到服务器上改 ZONE 文件的历史。

　　同时后端数据最好落到数据库里，这样做一些查询的时候会方便很多。比如我要查所有解析的 IP 落在外部而非校内 IP 的域名，数据库里只要一条 SQL 就搞定了，而 ZONE 文件的话就得写脚本了。

　　大家可能看过前阵子 GitHub 的 dns-infrastructure-at-github 这篇文章。这里面 GitHub 说他们以前的 DNS 架构就是两台服务器，包含了缓存，递归和权威服务。文章里没说用的是啥软件，不过 8 成是 Bind 吧。

　　我们学校之前的 DNS 架构也是如此，两台 Bind 做完所有的事情。我所了解的许多学校 DNS 架构亦是如此。很多地方的 DNS 架构都是这样子，简单，稳定。

　　我们将两台主递归服务器默认通过链路质量稍差一点，但带宽比较充裕的 ISP 进行递归。同时，在链路质量较好的 ISP 上再放两台递归服务器，将部分域名 Forward 给他去递归，从而在基本不降低用户访问体验的情况下，充分利用两条链路的带宽。

　　我们根据两条不同的链路做了两套权威服务，一套解析 ISP-1 的地址，另一台则解析为 ISP-2 的地址。然后在这两套权威服务之前，放了两台 dnsdist 作为边缘节点。

　　在数据中心内，我们需要一些私有的内部域名来做点服务注册之类的活。这些域名我们希望只能被我们数据中心内的服务器们请求到，普通的园区用户无法请求。类似的，我们在私有的权威服务之前，使用 dnsdist 进行 ACL 过滤。这两台 dnsdist 就作为数据中心的 DNS 服务提供给服务器使用。仅匹配数据中心网段的服务器允许解析，并转发私有的域名请求给权威服务器，其他请求则转发给园区的主递归服务。普通用户的请求则无法匹配 ACL 将被拒绝。

　　与 Bind 最大的区别就在监控上了。Powerdns 内置了大量的性能指标项，我们可以非常容易的去采集这些指标，然后推送给我们的监控系统。详细的指标可以参看官网说明：

　　实际上我们可以看出来，对于规模不是很大的 DNS 而言，是不需要 DNS 的负载均衡的。因为在达到单机的性能瓶颈之前，cache 的命中率才是决定请求平均延迟的主要因素。我们做双机的唯一目的只是冗余而已。

　　Powerdns 的单机性能，根据 官网介绍，大概能 HOLD 住亿级的请求量，所以通常不会有什么压力的~

　　powerdns 由于提供了丰富的 API 接口，因此社区内有很多适配的 WEB 前端可以选择。

　　然而既然我们的后端已经是 MySQL 了，所以完全可以用 MySQL 同步来做嘛。因此我们把 Powerdns 的类型设置为 Native，并且配置了两台权威服务器的 MySQL 进行主从同步。MySQL 的主从同步很可靠，同时 binlog 也能够方便的进行回退。

　　由于我们把数据放到了 MySQL 里，因此现在做一些复杂的记录查询变的非常容易了。例如我们需要查一下某个网段内的所有 A 记录解析。换以前可能得对着 Zone 文本写脚本了。现在只要一条 SQL 语句就搞定了：

　　同样，由于现在数据在 MySQL 内，数据备份也变得非常容易了。我们可以使用 MySQL 的 binlog 机制，很容易的实现数据的增量备份。再辅以每天一次全量的备份，数据的备份机制也比过去来的更完善了

　　新的架构上线之后，通过管理权限的下放和自动化的 API 调用，管理负担降低了，管理透明度提升了。整个结构清晰，易于维护。通过多链路的优化，我们在基本不降低用户的网络访问质量的同时，尽可能地利用了每一条 ISP 链路。

　　冯骐，华东师范大学信息部门工程师，上海教育城域网管理员。对网络、运维开发等有丰富经验。热爱开源，Open-Falcon 社区成员，开发 / 维护有多个 Open-Falcon 适配的监控插件。如：交换机监控、Windows 监控、vSphere 监控等。

　　AI 大数据、微服务、大前端、各业务形态的架构如何落地？2017 年有哪些值得学习和借鉴的实践经验？给你来自 100+ 顶尖架构师的经验总结：ArchSummit 全球架构师峰会将于 12 月 8-11 日北京举行，部分分享嘉宾如下：

　　目前大会 9 折报名最后一周，大会完整演讲目录，可识别下方二维码了解，期待和你一同进步！返回搜狐，查看更多