DNS随笔2-混乱的结构

NS记录和授权委托

把所有DNS记录看作是数据库中的记录，那么所有授权服务器就是这个数据库的存储节点。

随便打开一篇介绍DNS的文章，都会在开头的位置画一副DNS域名树状示意图，表示域名记录的数据结构。其实这是有误导性质的叙述，算法中的数据结构是定义规则后插入数据可自动形成的，而DNS的树形结构完全是人工定义的，DNS协议只是约定了哪类dns记录可以放在哪类存储节点中，哪类存储节点可以挂在哪类存储节点之下。真正增加dns记录的时候，完全是靠人和商务流程来决定你的DNS记录存放在哪儿。例如：

nease.net，这是网易的域名，按前文的描述方式来说，所有形如*.nease.net的dns记录可以存放在哪儿呢？按照DNS协议约定，其实可以存放在根服务器（.）上，可以存放在net授权域服务器上，也可以存放在nease.net的授权域服务器上。但是受商务流程的约束，必须要提供nease.net的授权域服务器来存放这些记录，而nease.net授权域服务器按照DNS协议约定，可以挂在根服务器下，也可以挂在net授权域服务器下，同上，商务流程的约束，只能挂在net授权域服务器下。

既然是一颗树，就要有从父存储节点指向子存储节点的指针，这在DNS协议中约定使用NS记录来实现。例如：

在net授权域服务器的DNS记录中，就会有nease.net的NS记录，这个NS记录指向的就是nease.net的授权域服务器。

nease.net. IN NS ns2.nease.net.
nease.net. IN NS ns3.nease.net.
nease.net. IN NS ns4.nease.net.

这里，这些NS记录的作用就是起标示存储节点的作用，当所谓递归查询在net授权服务器上得到这些记录的时候，只是确认了和nease.net相关的DNS记录在这些存储节点上，需要去诸如ns2.nease.net的服务器上进行进一步的查询。另一层含义就是，这几个NS记录不是数据库中的数据，而是数据库中用来标识存储结构的。真正的数据在ns2.nease.net上：

nease.net. 18000 IN NSns3.nease.net.
nease.net. 18000 IN NSns2.nease.net.
nease.net. 18000 IN NSns4.nease.net.

这是DNS协议中不合理的设计：

一方面，从数据查询的角度看，DNS记录保存在两个地方，应该用哪个，是否需要保持数据的一致性，都成了问题。在DNS协议中，后者的结果被标识为权威的，前者的结果被标识为参考（Referral），对客户端应用而言应该使用后者。从数据存储的角度看，NS记录用于寻址，只要得到前者的结果就足以进行后续的查询。这个问题的根源应该是应用层协议中的数据和数据管理用数据混淆在一起导致的。

另一方面，从逻辑关系上看，NS记录中数据还是域名记录，还需要在这个数据库中进行查询才能定位（最终是要得到IP地址），无可避免会出现循环的情况。现有协议是通过在父节点增加A记录的方式打破闭环，象上例中就需要在net授权服务器的DNS记录中增加ns2.nease.net等三条A记录，这些A记录是在数据查询过程中用来寻址的，所以不是给客户用的应用数据，DNS协议给它们一个类别：glue。很蹩脚的设计，而且没有彻底解决问题，因为多个域名的NS记录指向之间还是可能会形成闭环。

所以DNS中很多令人迷惑的特性，不是多么高深的东西，实在是设计缺陷。

1. http://tools.ietf.org/html/rfc2181