我目前正在对我工作地点的 DNS 服务进行基准测试。此测试产生的一个较大异常是,大量域名在某些情况下查询返回 NXDOMAIN 响应,而在其他情况下我得到对 MX 查询的有效响应。
(所讨论的域名是外部的)
虽然这可能是由于一对权威服务器之间的配置差异造成的,但我意识到当我尝试解析没有粘合记录的域时,我不知道会得到什么样的响应。(如果能提供权威来源的链接将不胜感激)。
答案1
严格来说,粘合仅在一种情况下是必要的:名称服务器属于由同一区域定义的区域切口。RFC 1034§4.2.1明确了这一点,强调一下:
区域结构的目标之一是任何区域都拥有与任何子区域的名称服务器建立通信所需的所有数据。也就是说,父区域拥有访问其子区域的服务器所需的所有信息。命名子区域的服务器的 NS RR 通常不足以完成此任务,因为它们命名了服务器,但没有提供服务器的地址。特别是,如果名称服务器的名称本身位于子区域中,我们可能会面临这样的情况:NS RR 告诉我们,为了了解名称服务器的地址,我们应该使用我们希望了解的地址联系服务器。为了解决这个问题,区域包含“粘合”RR,它们不是权威数据的一部分,而是服务器的地址 RR。仅当名称服务器的名称“低于”截止值时,这些 RR 才是必要的,并且仅用作引荐响应的一部分。
认为在注册局/注册商层面“需要”粘合的想法是一种普遍存在的谬论,主要源于只有少数 gGTLD 可供选择的时代。随着可供选择的 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
。遇到这种情况时,需要通过 TLD 进行递归com
,以获取其中一个名称服务器的 IP 地址。在此过程中遇到的任何粘合都将照常进行。我不会引用RFC 1034§4.3.2因为重述基本操作原理有点愚蠢。
简而言之,只有在符合以下标准的情况下,胶水才是强制性的:或者特定注册商(或注册局)的政策要求这样做。后者要求这样做并不一定代表前者。如果遇到 TLD 的无缝授权,则一切照常。
如果胶水在一个场景中丢失了必需的(我怀疑这是你真正的问题),没有其他名称服务器可以提供权威响应,这显然是 的情况SERVFAIL
。NXDOMAIN
这意味着可以到达权威服务器,但这里的情况并非如此。定义区域切割的服务器是不是对于低于切割的数据具有权威性(RFC 2181§6.1),无法连接权威服务器就意味着你已经走进了死胡同。