主页 / server / 问题 / 785230
Accepted
symcbean
Asked: 2016-06-22 01:15:56 +0800 CST

DNS 服务器如何响应丢失的粘合记录？

  • 772

我目前正在我的工作地点对 DNS 服务进行一些基准测试。这引发的较大异常之一是大量域，在某些情况下，查找返回 NXDOMAIN 响应，而在其他情况下，我得到对 MX 查找的有效响应。

（有问题的域是外部的）

虽然这可能是由于一对权威服务器之间的配置差异造成的，但我意识到当我尝试解析没有粘合记录的域时，我不知道会得到哪个响应。（将不胜感激链接到权威来源）。

domain-name-system

1 个回答

  1. Best Answer

    严格来说，胶合仅在一种情况下是必需的：名称服务器落入由同一区域定义的区域切割中。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。当遇到这种情况时，有必要通过comTLD 进行递归以获得其中一个名称服务器的 IP 地址。沿途遇到的任何胶水都将照常进行。我不会在这里引用RFC 1034 §4.3.2，因为重申基本操作基础有点愚蠢。

    简而言之，只有在特定注册服务商（或注册管理机构）的标准或政策都要求时，粘合才是强制性的。后者要求它不一定是前者的指示。如果遇到来自 TLD 的无胶授权，则一切照旧。

    如果在需要胶水的情况下缺少胶水（我怀疑您的实际问题），并且没有其他名称服务器可用于提供权威响应，那将是SERVFAIL. NXDOMAIN将意味着可以访问权威服务器，但这里不是这种情况。定义区域切割的服务器对切割下的数据没有权威（RFC 2181 §6.1），无法访问权威服务器意味着您已经走到了死胡同。

    • 0

相关问题