我目前正在做我的工作地点的DNS服务的一些基准testing。 其中一个更大的反常现象是大量的域名，在某些情况下，查询返回了一个NXDOMAIN响应，而在其他情况下，我得到了对MX查询的有效响应。
（有问题的领域是外部的）
尽pipe这可能是由于一对权威服务器之间的configuration不同所致，但我意识到当我尝试parsing没有粘合logging的域时，我不知道该期待什么响应。 （链接权威来源将不胜感激）。
严格地说，只有在一种情况下才需要胶水：名称服务器落在同一个区域定义的区域内。 RFC 1034§4.2.1使这个明确，强调我的：
区域结构的目标之一是任何区域都具有与任何子区域的名称服务器build立通信所需的所有数据。 也就是说，父区域具有访问其子区域的服务器所需的所有信息。 命名子域服务器的NS RR往往不足以完成此任务，因为他们命名服务器，但不给他们的地址。 特别是，如果名称服务器的名称本身在分区中，我们可能面临的情况是，NS RR告诉我们，为了学习名称服务器的地址，我们应该使用我们希望的地址学习。 为了解决这个问题，一个区域包含不是权威数据一部分的“粘合”RR，并且是服务器的地址RR。 这些RR只在名称服务器的名称在剪切“下面”时才是必需的，并且仅用作推荐响应的一部分。
在注册机构/注册商层面“粘合”是一种普遍的谬误，大部分是在gGTLD数量可供select的时代才出现的。 随着可供select的顶级域名（TLD）数量逐年增加，遇到无缝隙的顶级域名（TLD）推荐变得越来越普遍。 以goo.gl为例：
$ dig @d.nic.gl +noall +authority +additional goo.gl goo.gl. 86400 IN NS ns4.google.com. goo.gl. 86400 IN NS ns3.google.com. goo.gl. 86400 IN NS ns1.google.com. goo.gl. 86400 IN NS ns2.google.com.
请注意这里显示的附加数据缺乏。 gl并不需要为com内部的任何东西提供com 。 遇到这种情况时，需要通过com TLD进行recursion以获取其中一个名称服务器的IP地址。 正常情况下，沿途遇到任何胶水。 我不会在这里引用RFC 1034§4.3.2 ，因为重申基本的操作基础有点愚蠢。
简而言之，只有在特定注册商（或注册pipe理机构）的标准或政策要求的情况下，粘合才是强制性的。 后者要求它不一定是前者的迹象。 遇到来自顶级域名（TLD）的无缝授权时，只是照常营业。
如果在需要的情况下（您怀疑我的实际问题）缺less胶水，并且没有其他名称服务器可用于提供权威响应 ，那么这将是SERVFAIL一个明确的情况。 NXDOMAIN将意味着可以访问权威的服务器，这里不是这种情况。 定义区域切割的服务器对裁剪下面的数据（ RFC 2181§6.1 ） 没有权威性，而无法访问权威服务器意味着你已经到了死胡同。