我为什么创建DNSbed

创建DNSbed的目的很简单，一是手工配置和管理BIND智能DNS服务器很麻烦，二是市面上目前没有适合我的智能DNS服务器。

搭建一套智能DNS系统（包括设置好主从同步）不难，但是麻烦，手工去改配置文件不直观，而且容易出错。

也有很多基于WEB的DNS管理系统，但它们的后台基本都是BIND + DLZ。我不喜欢DLZ，它使BIND的查询性能严重下降。而且，使用DLZ后，BIND的Notify机制就没有了，主从之间的ZONE同步依靠数据库复制来实现。在网络不好的情况下，这个机制很不靠谱。

国内在智能DNS方面做得最好的就是DNSPod。DNSPod不是用的BIND，是自己实现的DNS解析系统。这个系统我分析过，并不是标准DNS实现。它是在网络低层拦截DNS请求，并通过字符串比对来解析域名的。例如，对于www.abc.com的查询请求到达DNSPod后，它在网络层或传输层处理这个请求（而不是像BIND一样在应用层），拿到域名并查询数据库，将查询结果返回给用户。在DNSPod里，没有ZONE的概念，一切皆是字符。

这个概念实际上是跟F5学的。我之前在使用F5的3DNS时，就发现F5在内核层拦截DNS包，对于命中wildip的直接在内核层就应答了，非wildip的普通域名才转发给应用层，由BIND来处理。F5的wildip能实现复杂的负载均衡和很高的查询性能，它实际是由内核DNS来做解析，而不是BIND解析的。

BIND处理一个域名查询要复杂的多，它严格遵循DNS相关协议。例如查询mail.nsbeta.info这个域名，对于一台公共DNS缓存服务器，其解析过程如下：

对BIND而言，它有ZONE的概念，严格支持ZONE递归查询。也就是说，对于这样一条域名：s1.s2.s3.abc.com，BIND很清楚它位于哪个ZONE里，由哪个NS来权威解析。但是对类DNSPod系统而言，无法区分这个域名位于哪个ZONE。如果用户在DNSPod上设置了如下3个域：
s2.s3.abc.com
s3.abc.com
abc.com

那么s1.s2.s3.abc.com这个记录，可以位于上述任何一个域里。如果abc.com的NS服务器也根据字符匹配命中，返回这个域名的权威应答，就违背了DNS协议，其他公共DNS服务器会很困惑因而引发问题。对BIND而言，则不会发生这种情况。如果s1.s2.s3.abc.com的查询到了abc.com的NS服务器，它会返回一个引用，引导用户查询s3.abc.com的NS服务器。同样，请求到了s3.abc.com的NS服务器，它仍然返回一个引用，引导用户查询s2.s3.abc.com的NS服务器。最终查询到了s2.s3.abc.com的NS服务器，由这个服务器作出权威应答。

所以对于DNSPod这类非标准系统，我个人并不感兴趣。当然，DNSPod的用户体验做得好，用起来顺手，这点很赞。

今年过年时，在家呆着没太多事做，就想为何不自己做一套WEB DNS解析系统。说做就做，从初一到初八，每天都花半天时间写程序，很快后台解析系统就写好了。基础架构是BIND9 View + TSIG Key + DNS动态扩展。核心组件还是BIND，没有使用广泛应用的BIND DLZ，而是自己写了一套动态扩展模块，可以灵活增加ZONE和DNS记录。抛弃DLZ的好处是可以全部利用BIND的高查询能力，不会导致性能下降，而且水平扩容非常方便。例如，水平增加一台名字服务器，只需要几分钟就可配置好，不依赖任何数据库的东西。当然，在WEB系统里我也用了Mysql，但这个只是作为管理用途，例如保存用户提交的ZONE与DNS记录数据，与BIND完全无关。在Mysql与BIND之间有一套Map系统，就是我的动态扩展模块。

后台写好后，就请之前的同事写了一套WEB模板。然后套模板、调试，大概花了半个月时间，在今年2月底这个系统就上线了。

做好以后，一直没怎么维护，主要是时间和精力有限。DNSbed也只是很简单的一个系统，实现了基本智能解析功能，其他细节例如统计、暂停、搜索功能都没有。而且，目前最不方便的地方是，对于每个域名，都要在电信、联通、教育、默认四个线路上添加记录。因为BIND View就是这个样子，当时我也没考虑太多，把一切交给用户定制。现在觉得这点的确是不太方便，增加用户的工作量。今后有时间改版，先把这个问题改正过来。