现在是凌晨4点，处理珠海机房的烂事情，并顺便写下这篇博客。希望我的头脑是清醒的。
很多人跟我反馈，他们的DNS系统基本工作正常，但偶尔不正常，不知道是哪里出了问题。
这种现象，很可能与胶水记录有关，NS的胶水记录（glue）与权威记录不一致，导致查询异常。
对于顶级域名如example.com，它的胶水记录就是在上一级DNS里注册的记录，见我前一篇博文“为什么DNS服务器必须注册”。假设注册了如下NS服务器：
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
ns1.example.com. IN A 1.2.3.4
ns2.example.com. IN A 5.6.7.8
当一个解析器（如DNS Cache）查询example.com的记录时，它可能从根查起（如果它的Cache里没有任何东西），到了.com的NS，获取到glue，得到两个NS的IP地址1.2.3.4和5.6.7.8，然后解析器跑到这2个IP地址去继续查询想要的记录。
很多情况下，用户的NS服务器变更了，但是没有更新glue。假如变更后，权威NS记录如下：
ns1.example.com. IN A 11.22.33.44
ns2.example.com. IN A 55.66.77.88
如果glue没有跟着变更的话，当一个从上到下的查询发生时，在.com的NS那里就会获取到错误的glue，解析器到错误的NS服务器上去查询，就会导致异常发生。
在这种情形下，为什么大部分时间查询还是正常，只是偶尔不正常呢？这就与DNS Cache的实际查询流程有关，请见我之前的博文“我为什么创建DNSBED”，里面有个图描述。解析器实际是从低级域名的NS开始查起的。例如查询abc.example.com时，解析器先查abc.example.com是否有NS，再查example.com的NS有无缓存住。如果缓存住了，直接从缓存里拿NS的IP地址。请注意只有权威记录才允许被缓存，也就是说解析器缓存的是权威NS记录，即11.22.33.44和55.66.77.88这2个IP地址。这样，只要缓存不失效，解析器就能跑到正确的NS服务器上去查询域名。但这实际上是误打误撞。如果解析器不使用缓存，严格跟随引用（如dig +trace一样），那么只要glue与权威NS记录不一致，就会发生解析问题。
您也许会问，如果glue都不正确，解析器如何能有机会得到权威解析呢？这里的情况很复杂，例如，ns1和ns2只有一个变更了，并且没有变更glue，那么解析器仍有可能从另一个那里拿到权威解析。还有一种更常见的情况，请见我下一篇博文描述。
总之，DNS管理员必须维护NS的权威记录与注册的glue严格一致，这样才能避免发生一些复杂而难以跟踪的域名解析问题。