什么是胶水记录？

Question 1

粘合记录是指由对区域不具有权威性的 DNS 服务器提供的记录，用于避免 DNS 区域出现无法建立依赖关系的情况。

假设我拥有的 DNS 区域example.com。我希望拥有托管此域的权威区域的 DNS 服务器，以便我可以实际使用它 - 添加域根的记录、、www等mail。因此，我将名称服务器放入注册中以委托给它们 - 这些始终是名称，因此我们将输入ns1.example.com和ns2.example.com。

这里有诀窍。TLD 的服务器将委托给 whois 记录中的 DNS 服务器 - 但它们位于内example.com。它们尝试查找ns1.example.com，询问.com服务器，然后被转回... ns1.example.com。

粘合记录的作用是允许 TLD 服务器在响应区域查询时发送额外信息example.com- 也发送为名称服务器配置的 IP 地址。它不是权威的，但它是指向权威服务器的指针，允许解决循环。

Answer

粘合记录是指由对区域不具有权威性的 DNS 服务器提供的记录，用于避免 DNS 区域出现无法建立依赖关系的情况。

假设我拥有的 DNS 区域example.com。我希望拥有托管此域的权威区域的 DNS 服务器，以便我可以实际使用它 - 添加域根的记录、、www等mail。因此，我将名称服务器放入注册中以委托给它们 - 这些始终是名称，因此我们将输入ns1.example.com和ns2.example.com。

这里有诀窍。TLD 的服务器将委托给 whois 记录中的 DNS 服务器 - 但它们位于内example.com。它们尝试查找ns1.example.com，询问.com服务器，然后被转回... ns1.example.com。

粘合记录的作用是允许 TLD 服务器在响应区域查询时发送额外信息example.com- 也发送为名称服务器配置的 IP 地址。它不是权威的，但它是指向权威服务器的指针，允许解决循环。

Question 2

我请求将此答案从重复问题中合并进来，因为现有答案并未解释该ADDITIONAL部分的作用。

要了解其工作原理，请输入以下命令： dig +trace +additional google.com SOA

这将从根服务器 ( +trace) 开始跟踪名称服务器权限。添加+additional还将向您显示ADDITIONAL每个 DNS 服务器响应的部分。通常，大多数人会从QUESTION和ANSWER部分的角度来考虑 DNS，但ADDITIONAL它也起着重要作用：如果名称服务器知道与答案相关的任何查询的答案，它可以预先在部分中提供这些答案，ADDITIONAL而无需客户端进行额外查询。

请注意，权威名称服务器google.com植根于其所权威的域下。（ns1.google.com，，ns2.google.com等等）

当你要求域名服务器提供域名的域名服务器列表时，他们通常会A在部分中提供 -type 记录（IP 地址）列表ADDITIONAL，而不仅仅是NS-type 答案：这些被称为胶水记录，用于防止循环依赖。在这种情况下，这些A记录由 TLD（.com、.org 等）名称服务器根据某人提供给负责该域的 DNS 注册商的 IP 地址提供。通常可以通过登录他们提供给您的管理 Web 界面来更改它们。

（免责声明：AAAA包含 IPV6 地址的记录也可以作为粘合的一部分提供，但为了简单起见，我省略了这一点。）

Answer

我请求将此答案从重复问题中合并进来，因为现有答案并未解释该ADDITIONAL部分的作用。

要了解其工作原理，请输入以下命令： dig +trace +additional google.com SOA

这将从根服务器 ( +trace) 开始跟踪名称服务器权限。添加+additional还将向您显示ADDITIONAL每个 DNS 服务器响应的部分。通常，大多数人会从QUESTION和ANSWER部分的角度来考虑 DNS，但ADDITIONAL它也起着重要作用：如果名称服务器知道与答案相关的任何查询的答案，它可以预先在部分中提供这些答案，ADDITIONAL而无需客户端进行额外查询。

请注意，权威名称服务器google.com植根于其所权威的域下。（ns1.google.com，，ns2.google.com等等）

当你要求域名服务器提供域名的域名服务器列表时，他们通常会A在部分中提供 -type 记录（IP 地址）列表ADDITIONAL，而不仅仅是NS-type 答案：这些被称为胶水记录，用于防止循环依赖。在这种情况下，这些A记录由 TLD（.com、.org 等）名称服务器根据某人提供给负责该域的 DNS 注册商的 IP 地址提供。通常可以通过登录他们提供给您的管理 Web 界面来更改它们。

（免责声明：AAAA包含 IPV6 地址的记录也可以作为粘合的一部分提供，但为了简单起见，我省略了这一点。）

Question 3

经过长时间的搜索和阅读大量关于胶水记录的文章，并且仍然不明白它们是什么或如何制作它们之后，我终于找到了一个答案，而且这是一个非常简单的答案。

据我所知，没有从某个地方发送的神奇的额外信息，这就是它的工作原理。

假设您的域名是 example.com，并且您想要使用自己的名称服务器 ns1.example.com 和 ns2.example.com，那么您至少需要两个 DNS 服务器。

ns1.example.com 的 IP 为 192.0.2.10
ns2.example.com 的 IP 为 192.0.2.20

为了使其现在正常工作，您需要顶级域名所有者将以下记录放入他们的 DNS 中。

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

这两个 A 记录是粘合记录，它们需要位于顶级域名（在本例中为 .com），并且并非所有注册商都能为您完成此操作。

如果这是错误的，请纠正我。我只是想尝试以一种简单的方式为那些找不到正确答案的人解释。

Answer

经过长时间的搜索和阅读大量关于胶水记录的文章，并且仍然不明白它们是什么或如何制作它们之后，我终于找到了一个答案，而且这是一个非常简单的答案。

据我所知，没有从某个地方发送的神奇的额外信息，这就是它的工作原理。

假设您的域名是 example.com，并且您想要使用自己的名称服务器 ns1.example.com 和 ns2.example.com，那么您至少需要两个 DNS 服务器。

ns1.example.com 的 IP 为 192.0.2.10
ns2.example.com 的 IP 为 192.0.2.20

为了使其现在正常工作，您需要顶级域名所有者将以下记录放入他们的 DNS 中。

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

这两个 A 记录是粘合记录，它们需要位于顶级域名（在本例中为 .com），并且并非所有注册商都能为您完成此操作。

如果这是错误的，请纠正我。我只是想尝试以一种简单的方式为那些找不到正确答案的人解释。

Question 4

嗯，这些是三问题：

DNS 粘合记录到底是什么（简单来说）？

为什么需要它们以及

它们是如何工作的？

第一个问题的简短回答如果没有上下文可能就没有什么意义，因为后两个问题的回答有些冗长。那么，这里有另一种解释，其中引用了 RFC 的历史，以便为术语提供一些背景，特别是：
RFC 822“ARPA 互联网文本消息格式标准”1982，https://www.rfc-editor.org/rfc/rfc822.html
，现已被RFC 5322“互联网消息格式”2008取代，https://www.rfc-editor.org/rfc/rfc5322；
RFC 882“域名 - 概念和设施”1983，https://www.rfc-editor.org/rfc/rfc882，该规范早于并已被
RFC 1034“域名 - 概念和设施”1987 所取代，https://www.rfc-editor.org/rfc/rfc1034，以及；
RFC 1035“域名 - 实施和规范”1987，https://www.rfc-editor.org/rfc/rfc1035；中间的
RFC 952“DoD 互联网主机表规范”1985，https://www.rfc-editor.org/rfc/rfc952.html；
RFC 1123“互联网主机要求--应用和支持”1989，https://www.rfc-editor.org/rfc/rfc1123.html，特别是；
RFC 2181“DNS 规范说明”1997，https://www.rfc-editor.org/rfc/rfc2181，以及；
RFC 2535“域名系统安全扩展”1999，https://www.rfc-editor.org/rfc/rfc2535。

现在，简要回答第一个问题：DNS“粘合记录”是一个口语术语 - 未在 RFC 中定义 - 指的是一种 DNS IP 地址资源记录，即“A”记录或“AAAA”记录。当 IP 地址记录提供的地址将路径链接到委派“子区域”/“域名”的公共辅助 DNS 协议服务器时，IP 地址记录也是“粘合记录”，特别是，该委派“子区域”的公共辅助 DNS 协议服务器“域名”也是在，和直接受管辖，该子区域。在这里 - 因为我没有在 RFC 中找到对此的明确说明 - 网络管理员只需推断，当委托的“子区域”也位于该子区域中，并直接受该子区域中的权限控制时，则父区域必须还提供一个或多个 IP 地址记录，最终链接到子区域权威性DNS 协议服务器。“粘合记录”都是关于“权威”和“非权威”服务器的相互作用，其中，通过设计，“父区域”是不是对于“子区域”具有权威性。

然后，有一个警告，提出于NS 记录和胶水记录有什么区别？，由 Ladadadada 提出，实践中存在不确定性，也许在 RFC 中没有完全澄清，即是否有任何特定的 DNS 协议客户将会或不会遵循一条路径，然后核实链接子区域 DNS 协议服务器也是权威性该子区域的服务器，有效地验证 IP 地址是否匹配。存在这样的可能，即“粘合记录”IP 地址可能导致权威服务器，而“名称服务器”资源记录可能导致不同的，因此不一致，IP地址为一个或多个权威性该子区域的 DNS 协议服务器。服务器地址可能已验证。服务器地址可能未验证，IP 地址已过期，并且该服务器的区域文件也可能“部分”过期，具有正确的“名称服务器”记录，但为其他资源提供过期或错误的答案。当然，这种情况意味着 DNS 管理错误，因此这只是一个警告。实际上，这种情况“不应该”发生。

当读者需要“常识”并且经常使用“重载”术语时，通过 RFC 回答后两个问题会变得复杂，在实践中，在常见用法中，同一个术语用于指代两个，有时更多，不同的东西或不同的抽象。这里要认识到的另一件事是互联网消息传递和域名系统在开发过程中的早期关联，以及这种关联如何影响域名系统 RFC 中互联网消息传递术语的使用，即当时的“常识”。

具体来说，这导致各个 RFC 中“域名”一词的使用非常不一致，该术语在不同上下文中可能指：

“主机域名”，或
“子区域域名”。

这些术语可以从 RFC 中推断出来。作为“常识”，“主机”本身既是 1) 具有物理网络接口的机器，也是 2) 已分配 IP 地址的操作系统 IP“套接字”接口。“主机域名”术语来自 RFC 1123，其中明确使用了该术语。

“子区域域名”这一术语可能来自多个 RFC。我们看到“域名”是“子域”，最初出现在 RFC 822 中，后来出现在 RFC 2181 中，或者“子区域”是“子区域域名”，其他 RFC（尤其是 RFC 1035 和 RFC 2535）中也隐含了“子区域”一词。

这些“域名”是两个截然不同的东西，它们都可以用作：

DNS 协议数据包中“所有者名称”的值以及“主文件”或“区域文件”资源记录左侧的“所有者”，也可以作为
NS、MX 或 CNAME 资源记录中的 RDATA“名称集合”值，或 SOA 资源记录中的 MNAME“名称集合”，在数据包中以及区域文件的右侧，如 RFC 1034 和 RFC 1035 中所述。

特别是在早期的 RFC 952 中，我们看到这两个不同的“域”概念被简单地“混为一谈”：

GRAMMATICAL HOST TABLE SPECIFICATION

  A. Parsing grammar
  ...
     <domainname> ::= <hname>
     <official hostname> ::= <hname>

另一个容易混淆的地方是“NS 资源记录”，根据上下文，它也有两种截然不同的含义。我们可以从下面的 RFC 2181 第 6.1 节中读到https://www.rfc-editor.org/rfc/rfc2181#section-6：

6.1. 区域授权
区域的授权服务器在区域起源的 NS 记录中枚举，这些记录与授权起始 (SOA) 记录一起是每个区域中的强制性记录。此类服务器对区域中不属于其他区域的所有资源记录具有授权。指示区域切割的 NS 记录是所创建子区域的属性，该子区域起源的任何其他记录或其任何子域也是如此。区域的服务器不应返回与另一个区域的名称相关的查询的授权答案，其中包括区域切割处的 NS 记录，也许还有 A 记录，除非它恰好也是其他区域的服务器。

并特别注意短语“NS 记录...是每个区域的强制性记录”，另外请注意：

除了下面立即提到的 DNSSEC 情况之外，服务器应该忽略 NS 记录以外的数据，以及定位 NS 记录中列出的服务器所需的 A 记录，这些数据可能恰好在区域切割时在区域中配置。

但与此同时，我们还在前面的第 6 节中读到：

... 区域切割的存在由父区域中指定子区域来源的 NS 记录的存在来指示。子区域不包含对其父区域的任何明确引用。

因此，读者可以自行推断，区域文件中存在两类非常不同的 NS 资源记录：

这些强制性记录具有与区域“原点”域本身完全相同的“标签”，为自描述权威公共辅助 DNS 协议服务器提供“主机域名”。它们指的是这区域和权威性。和
那些带有标签的可选记录不是精确匹配区域源域，从而指定现已扩展的子区域源域，并将路径链接到子区域的公共辅助 DNS 协议服务器名称。它们指的是其他区域和不权威。这些记录只是“最佳猜测”，特别要记住的是，这个父区域不能对子区域具有权威性。

我们应该花点时间意识到第二类 NS 记录可能然后也要求当委派的“子区域”也位于该子区域中，并直接受该子区域中的权限控制时，将相应的地址记录作为“粘合记录”纳入其中，如前所述。我们还应该意识到，对于“子区域域名”，这些完全相同的 NS 记录及其相关的“粘合记录”需要包含在子区域的区域文件中（可能被认为是“冗余包含”），因为权威性子区域域的公共辅助 DNS 协议服务器及其 IP 地址的表达。再次提醒，"父"区域是绝不对于“子”区域具有权威性，即使父区域文件包含并已经提供了完全相同的信息 - 永远不会对子区域的 NS 记录具有权威性，也永远不会对任何其他类型的子区域资源记录具有权威性。

现在来谈谈第二个问题，“为什么需要胶水记录吗？首先应该说，严格来说，胶水记录是不是根本不需要，前提是：

区域文件不描述任何涉及前面描述的第二类 NS 记录的子“区域域名”，或者
区域文件做包括描述子“区域域名”的 NS 记录，但同时，公众次要的子区域的 DNS 协议服务器是不是在直接管辖范围内之内那个儿童区域。

除非网络管理员正在配置需要委派子域的大型组织，并使用他们自己的自管理 DNS 协议服务器，否则不需要任何“粘合记录”。即便如此，大型组织也可能会非常谨慎地分发其 DNS 协议服务器在外面任何委托的子域，同样，如果这些服务器地址已经在其他地方（可能是由某些外部提供商）解析，则可能避免对“粘合记录”的任何需要。

“粘合记录”更可能是“虚荣”域名所需要的东西，或者是一个想要管理两个都自己的 DNS 协议服务器，和组织上游 DNS 提供商（可能是其 DNS 注册商）使用的区域文件。即便如此，也很可能只有注册商的区域文件才会有链接到其客户自己的 DNS 协议服务器的“粘合记录”，这些服务器很可能不是也被客户用来委托子区域域名。

但是，正如接下来对第三个问题的回答中提到的那样，“如何做他们的工作” - ”为什么“稍微复杂一点。DNS 的操作意味着遵循域组件层次结构的路径，如 RFC 882 中的“名称空间规范和术语”中所述，这最终需要在每次“区域切换”时从非授权服务器到授权服务器的“桥接” IP 地址。除非局限于“根”区域，否则总是区域沿着路径切向目标“域名”。“粘合记录”提供了跨区域切向的“桥梁”。

这里应该提到，为了了解历史背景，NS 记录和地址记录的传递机制。请注意，NS 记录在资源记录的左侧包含“子区域域名”，即“所有者”，在右侧包含“主机域名”，即 RDATA“规范名称”。这里还没有 IP 地址。为什么会这样？我们可以参考现已过时的 RFC 822 中的“常识”，第 6.2.3 节，https://www.rfc-editor.org/rfc/rfc822.html#section-6.2，其中明确指出：

6.2.3. 域术语
域引用必须是注册表、网络或主机的正式名称。它是名称子域内的符号引用。有时，需要绕过解析此类引用的标准机制，使用更原始的信息，例如网络主机地址而不是其关联的主机名。... 引用
ARPA
互联网内的域的域文字指定 32 位互联网地址，在四个 8 位字段中以十进制表示，如征求意见 #820“分配的号码”中所述。例如：
[10.0.3.19]
Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
       is  permitted  only  as  a means of bypassing temporary
       system limitations, such as name tables which  are  not
       complete.

或者换句话说，“域名”通常是不是IP 地址。因此，NS 记录的 RDATA 是“域名”，而不是 IP 地址，而单独的地址记录将此 NS RDATA“域名”与“ARPA Internet 特定”资源记录 RDATA（实际 IP 地址）相关联。因此，在这种情况下，地址记录也可能被称为“粘合记录”，而 NS 记录则不是。第二类 NS 记录是总是需要在父区域中标记“区域切割”，但可能需要相关的地址记录，或者可能不是需要，正如讨论的那样。

这里还有另一个关于术语的说明，涉及 SOA 资源记录以及“主”DNS 协议服务器和“公共辅助”服务器的区别。在 RFC 1035 第 3.3.13 节“SOA RDATA 格式”中，https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13，有：

MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

SOA records cause no additional section processing.

注意过去时，“曾是原始或主要来源”。同样，我们应该花点时间意识到，通常情况下，民众DNS 协议服务器也必然基本的该区域的服务器，而且“该区域的主要数据源”甚至不需要公开访问。虽然主服务器通常是公开访问的，但这并不是必需的。虽然主服务器也可能是公开的，仅有的区域的服务器，最好有冗余服务器。为了便于管理多个服务器，单个主服务器可以向一组辅助服务器进行“区域转移”或“权威转移” “AXFR”。那么，为了严谨起见，“主”服务器在 SOA 记录 MNAME 中指定，因此，所需的第一类 NS 资源记录的 RDATA 中指定的服务器是“公共辅助”服务器。不过，SOA MNAME 和 NS RDATA 名称也可能指同一台服务器。

最后，关于第三个问题，“如何粘合记录如何工作？”，反思客户端和各种服务器之间交换时 DNS 协议的隐含操作是有用的，这在 RFC 1034 中进行了讨论，尤其是第 5 节“解析器”，https://www.rfc-editor.org/rfc/rfc1034.html#section-5以及 RFC 1035 第 7 节“解析器实现”，一般而言，特别要注意第 7.2 节，https://www.rfc-editor.org/rfc/rfc1035#section-7.2：

一些要点：

解析器可能会遇到以下情况：SLIST 中列出的任何名称服务器都没有可用的地址，而列表中的服务器正是通常用于查找其自身地址的服务器。这种情况通常发生在粘合地址 RR 的 TTL 小于标记委派的 NS RR 时，或者解析器缓存 NS 搜索的结果时。解析器应检测到这种情况并在下一个祖先区域或根区域重新开始搜索。

客户端进行一系列查询，遍历域名层次结构，主要将子域组件解析为 IP 地址，通常首先找到“根”服务器“域名”，然后是其 IP 地址，然后是“全球顶级域”服务器“域名”，然后是其 IP 地址，然后是第三级“域名”，此时由父全球顶级域委派的“子区域域名”，并搜索此区域的 DNS 协议服务器的 IP 地址。全球顶级域的服务器将权威地提供一个“区域切割”，指定一个“子区域域名”。然后客户端将需要这个第三级“子区域域名”DNS 协议服务器的 IP 地址。但是，正如所讨论的，在每个“切割”中，按照域名层次结构，“父”区域是不是这权威性“子”区域的 DNS 协议服务器的 IP 地址来源，通过设计. 但是，客户端需要一个 IP 地址 - 从哪里来？

客户端可能会开始按照域名层次结构中的另一条路径搜索此 IP 地址，只有当客户端识别出具有为此子区域域名指定的 DNS 协议服务器的 IP 地址的“授权来源”的服务器以及所寻找的任何其他记录时，该路径才会结束。但无论如何，在从区域到子区域的每次“切换”中，客户端都必须有一个来自非权威的源，到该 IP 地址的“权威”源。这就是为什么“胶水记录”可能仅被称为有关服务器 IP 地址的“提示”。父区域服务器提供“最佳猜测”，即“建议”，将客户端从当前服务器重定向到“下一个”服务器，继续客户端搜索具有“权威来源”的服务器，最终声明权威地那这IP 地址是这目标“子区域域名”DNS 协议服务器的“主机域名”IP 地址。

“粘合记录”规定 IP 地址“桥接”非权威的源服务器最终权威性源服务器。客户端是否愿意验证当前服务器的 IP 地址是否与目标“子区域域名”的权威 DNS 名称服务器 IP 地址相匹配，由客户端自行决定。希望得到最好的结果 - 或者手动确认。可能完全不列出区域文件中的第一类自描述权威 NS 记录，并且仍然向客户端提供任何其他资源记录 - 只要客户端只是“希望得到最好的结果”并且实际上不检查 NS 记录及其关联的地址记录。

另请参阅 RFC 8499“DNS 术语”2019，https://www.rfc-editor.org/rfc/rfc8499.html。

Answer

嗯，这些是三问题：

DNS 粘合记录到底是什么（简单来说）？

为什么需要它们以及

它们是如何工作的？

第一个问题的简短回答如果没有上下文可能就没有什么意义，因为后两个问题的回答有些冗长。那么，这里有另一种解释，其中引用了 RFC 的历史，以便为术语提供一些背景，特别是：
RFC 822“ARPA 互联网文本消息格式标准”1982，https://www.rfc-editor.org/rfc/rfc822.html
，现已被RFC 5322“互联网消息格式”2008取代，https://www.rfc-editor.org/rfc/rfc5322；
RFC 882“域名 - 概念和设施”1983，https://www.rfc-editor.org/rfc/rfc882，该规范早于并已被
RFC 1034“域名 - 概念和设施”1987 所取代，https://www.rfc-editor.org/rfc/rfc1034，以及；
RFC 1035“域名 - 实施和规范”1987，https://www.rfc-editor.org/rfc/rfc1035；中间的
RFC 952“DoD 互联网主机表规范”1985，https://www.rfc-editor.org/rfc/rfc952.html；
RFC 1123“互联网主机要求--应用和支持”1989，https://www.rfc-editor.org/rfc/rfc1123.html，特别是；
RFC 2181“DNS 规范说明”1997，https://www.rfc-editor.org/rfc/rfc2181，以及；
RFC 2535“域名系统安全扩展”1999，https://www.rfc-editor.org/rfc/rfc2535。

现在，简要回答第一个问题：DNS“粘合记录”是一个口语术语 - 未在 RFC 中定义 - 指的是一种 DNS IP 地址资源记录，即“A”记录或“AAAA”记录。当 IP 地址记录提供的地址将路径链接到委派“子区域”/“域名”的公共辅助 DNS 协议服务器时，IP 地址记录也是“粘合记录”，特别是，该委派“子区域”的公共辅助 DNS 协议服务器“域名”也是在，和直接受管辖，该子区域。在这里 - 因为我没有在 RFC 中找到对此的明确说明 - 网络管理员只需推断，当委托的“子区域”也位于该子区域中，并直接受该子区域中的权限控制时，则父区域必须还提供一个或多个 IP 地址记录，最终链接到子区域权威性DNS 协议服务器。“粘合记录”都是关于“权威”和“非权威”服务器的相互作用，其中，通过设计，“父区域”是不是对于“子区域”具有权威性。

然后，有一个警告，提出于NS 记录和胶水记录有什么区别？，由 Ladadadada 提出，实践中存在不确定性，也许在 RFC 中没有完全澄清，即是否有任何特定的 DNS 协议客户将会或不会遵循一条路径，然后核实链接子区域 DNS 协议服务器也是权威性该子区域的服务器，有效地验证 IP 地址是否匹配。存在这样的可能，即“粘合记录”IP 地址可能导致权威服务器，而“名称服务器”资源记录可能导致不同的，因此不一致，IP地址为一个或多个权威性该子区域的 DNS 协议服务器。服务器地址可能已验证。服务器地址可能未验证，IP 地址已过期，并且该服务器的区域文件也可能“部分”过期，具有正确的“名称服务器”记录，但为其他资源提供过期或错误的答案。当然，这种情况意味着 DNS 管理错误，因此这只是一个警告。实际上，这种情况“不应该”发生。

当读者需要“常识”并且经常使用“重载”术语时，通过 RFC 回答后两个问题会变得复杂，在实践中，在常见用法中，同一个术语用于指代两个，有时更多，不同的东西或不同的抽象。这里要认识到的另一件事是互联网消息传递和域名系统在开发过程中的早期关联，以及这种关联如何影响域名系统 RFC 中互联网消息传递术语的使用，即当时的“常识”。

具体来说，这导致各个 RFC 中“域名”一词的使用非常不一致，该术语在不同上下文中可能指：

“主机域名”，或
“子区域域名”。

这些术语可以从 RFC 中推断出来。作为“常识”，“主机”本身既是 1) 具有物理网络接口的机器，也是 2) 已分配 IP 地址的操作系统 IP“套接字”接口。“主机域名”术语来自 RFC 1123，其中明确使用了该术语。

“子区域域名”这一术语可能来自多个 RFC。我们看到“域名”是“子域”，最初出现在 RFC 822 中，后来出现在 RFC 2181 中，或者“子区域”是“子区域域名”，其他 RFC（尤其是 RFC 1035 和 RFC 2535）中也隐含了“子区域”一词。

这些“域名”是两个截然不同的东西，它们都可以用作：

DNS 协议数据包中“所有者名称”的值以及“主文件”或“区域文件”资源记录左侧的“所有者”，也可以作为
NS、MX 或 CNAME 资源记录中的 RDATA“名称集合”值，或 SOA 资源记录中的 MNAME“名称集合”，在数据包中以及区域文件的右侧，如 RFC 1034 和 RFC 1035 中所述。

特别是在早期的 RFC 952 中，我们看到这两个不同的“域”概念被简单地“混为一谈”：

GRAMMATICAL HOST TABLE SPECIFICATION

  A. Parsing grammar
  ...
     <domainname> ::= <hname>
     <official hostname> ::= <hname>

另一个容易混淆的地方是“NS 资源记录”，根据上下文，它也有两种截然不同的含义。我们可以从下面的 RFC 2181 第 6.1 节中读到https://www.rfc-editor.org/rfc/rfc2181#section-6：

6.1. 区域授权
区域的授权服务器在区域起源的 NS 记录中枚举，这些记录与授权起始 (SOA) 记录一起是每个区域中的强制性记录。此类服务器对区域中不属于其他区域的所有资源记录具有授权。指示区域切割的 NS 记录是所创建子区域的属性，该子区域起源的任何其他记录或其任何子域也是如此。区域的服务器不应返回与另一个区域的名称相关的查询的授权答案，其中包括区域切割处的 NS 记录，也许还有 A 记录，除非它恰好也是其他区域的服务器。

并特别注意短语“NS 记录...是每个区域的强制性记录”，另外请注意：

除了下面立即提到的 DNSSEC 情况之外，服务器应该忽略 NS 记录以外的数据，以及定位 NS 记录中列出的服务器所需的 A 记录，这些数据可能恰好在区域切割时在区域中配置。

但与此同时，我们还在前面的第 6 节中读到：

... 区域切割的存在由父区域中指定子区域来源的 NS 记录的存在来指示。子区域不包含对其父区域的任何明确引用。

因此，读者可以自行推断，区域文件中存在两类非常不同的 NS 资源记录：

这些强制性记录具有与区域“原点”域本身完全相同的“标签”，为自描述权威公共辅助 DNS 协议服务器提供“主机域名”。它们指的是这区域和权威性。和
那些带有标签的可选记录不是精确匹配区域源域，从而指定现已扩展的子区域源域，并将路径链接到子区域的公共辅助 DNS 协议服务器名称。它们指的是其他区域和不权威。这些记录只是“最佳猜测”，特别要记住的是，这个父区域不能对子区域具有权威性。

我们应该花点时间意识到第二类 NS 记录可能然后也要求当委派的“子区域”也位于该子区域中，并直接受该子区域中的权限控制时，将相应的地址记录作为“粘合记录”纳入其中，如前所述。我们还应该意识到，对于“子区域域名”，这些完全相同的 NS 记录及其相关的“粘合记录”需要包含在子区域的区域文件中（可能被认为是“冗余包含”），因为权威性子区域域的公共辅助 DNS 协议服务器及其 IP 地址的表达。再次提醒，"父"区域是绝不对于“子”区域具有权威性，即使父区域文件包含并已经提供了完全相同的信息 - 永远不会对子区域的 NS 记录具有权威性，也永远不会对任何其他类型的子区域资源记录具有权威性。

现在来谈谈第二个问题，“为什么需要胶水记录吗？首先应该说，严格来说，胶水记录是不是根本不需要，前提是：

区域文件不描述任何涉及前面描述的第二类 NS 记录的子“区域域名”，或者
区域文件做包括描述子“区域域名”的 NS 记录，但同时，公众次要的子区域的 DNS 协议服务器是不是在直接管辖范围内之内那个儿童区域。

除非网络管理员正在配置需要委派子域的大型组织，并使用他们自己的自管理 DNS 协议服务器，否则不需要任何“粘合记录”。即便如此，大型组织也可能会非常谨慎地分发其 DNS 协议服务器在外面任何委托的子域，同样，如果这些服务器地址已经在其他地方（可能是由某些外部提供商）解析，则可能避免对“粘合记录”的任何需要。

“粘合记录”更可能是“虚荣”域名所需要的东西，或者是一个想要管理两个都自己的 DNS 协议服务器，和组织上游 DNS 提供商（可能是其 DNS 注册商）使用的区域文件。即便如此，也很可能只有注册商的区域文件才会有链接到其客户自己的 DNS 协议服务器的“粘合记录”，这些服务器很可能不是也被客户用来委托子区域域名。

但是，正如接下来对第三个问题的回答中提到的那样，“如何做他们的工作” - ”为什么“稍微复杂一点。DNS 的操作意味着遵循域组件层次结构的路径，如 RFC 882 中的“名称空间规范和术语”中所述，这最终需要在每次“区域切换”时从非授权服务器到授权服务器的“桥接” IP 地址。除非局限于“根”区域，否则总是区域沿着路径切向目标“域名”。“粘合记录”提供了跨区域切向的“桥梁”。

这里应该提到，为了了解历史背景，NS 记录和地址记录的传递机制。请注意，NS 记录在资源记录的左侧包含“子区域域名”，即“所有者”，在右侧包含“主机域名”，即 RDATA“规范名称”。这里还没有 IP 地址。为什么会这样？我们可以参考现已过时的 RFC 822 中的“常识”，第 6.2.3 节，https://www.rfc-editor.org/rfc/rfc822.html#section-6.2，其中明确指出：

6.2.3. 域术语
域引用必须是注册表、网络或主机的正式名称。它是名称子域内的符号引用。有时，需要绕过解析此类引用的标准机制，使用更原始的信息，例如网络主机地址而不是其关联的主机名。... 引用
ARPA
互联网内的域的域文字指定 32 位互联网地址，在四个 8 位字段中以十进制表示，如征求意见 #820“分配的号码”中所述。例如：
[10.0.3.19]
Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
       is  permitted  only  as  a means of bypassing temporary
       system limitations, such as name tables which  are  not
       complete.

或者换句话说，“域名”通常是不是IP 地址。因此，NS 记录的 RDATA 是“域名”，而不是 IP 地址，而单独的地址记录将此 NS RDATA“域名”与“ARPA Internet 特定”资源记录 RDATA（实际 IP 地址）相关联。因此，在这种情况下，地址记录也可能被称为“粘合记录”，而 NS 记录则不是。第二类 NS 记录是总是需要在父区域中标记“区域切割”，但可能需要相关的地址记录，或者可能不是需要，正如讨论的那样。

这里还有另一个关于术语的说明，涉及 SOA 资源记录以及“主”DNS 协议服务器和“公共辅助”服务器的区别。在 RFC 1035 第 3.3.13 节“SOA RDATA 格式”中，https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13，有：

MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

SOA records cause no additional section processing.

注意过去时，“曾是原始或主要来源”。同样，我们应该花点时间意识到，通常情况下，民众DNS 协议服务器也必然基本的该区域的服务器，而且“该区域的主要数据源”甚至不需要公开访问。虽然主服务器通常是公开访问的，但这并不是必需的。虽然主服务器也可能是公开的，仅有的区域的服务器，最好有冗余服务器。为了便于管理多个服务器，单个主服务器可以向一组辅助服务器进行“区域转移”或“权威转移” “AXFR”。那么，为了严谨起见，“主”服务器在 SOA 记录 MNAME 中指定，因此，所需的第一类 NS 资源记录的 RDATA 中指定的服务器是“公共辅助”服务器。不过，SOA MNAME 和 NS RDATA 名称也可能指同一台服务器。

最后，关于第三个问题，“如何粘合记录如何工作？”，反思客户端和各种服务器之间交换时 DNS 协议的隐含操作是有用的，这在 RFC 1034 中进行了讨论，尤其是第 5 节“解析器”，https://www.rfc-editor.org/rfc/rfc1034.html#section-5以及 RFC 1035 第 7 节“解析器实现”，一般而言，特别要注意第 7.2 节，https://www.rfc-editor.org/rfc/rfc1035#section-7.2：

一些要点：

解析器可能会遇到以下情况：SLIST 中列出的任何名称服务器都没有可用的地址，而列表中的服务器正是通常用于查找其自身地址的服务器。这种情况通常发生在粘合地址 RR 的 TTL 小于标记委派的 NS RR 时，或者解析器缓存 NS 搜索的结果时。解析器应检测到这种情况并在下一个祖先区域或根区域重新开始搜索。

客户端进行一系列查询，遍历域名层次结构，主要将子域组件解析为 IP 地址，通常首先找到“根”服务器“域名”，然后是其 IP 地址，然后是“全球顶级域”服务器“域名”，然后是其 IP 地址，然后是第三级“域名”，此时由父全球顶级域委派的“子区域域名”，并搜索此区域的 DNS 协议服务器的 IP 地址。全球顶级域的服务器将权威地提供一个“区域切割”，指定一个“子区域域名”。然后客户端将需要这个第三级“子区域域名”DNS 协议服务器的 IP 地址。但是，正如所讨论的，在每个“切割”中，按照域名层次结构，“父”区域是不是这权威性“子”区域的 DNS 协议服务器的 IP 地址来源，通过设计. 但是，客户端需要一个 IP 地址 - 从哪里来？

客户端可能会开始按照域名层次结构中的另一条路径搜索此 IP 地址，只有当客户端识别出具有为此子区域域名指定的 DNS 协议服务器的 IP 地址的“授权来源”的服务器以及所寻找的任何其他记录时，该路径才会结束。但无论如何，在从区域到子区域的每次“切换”中，客户端都必须有一个来自非权威的源，到该 IP 地址的“权威”源。这就是为什么“胶水记录”可能仅被称为有关服务器 IP 地址的“提示”。父区域服务器提供“最佳猜测”，即“建议”，将客户端从当前服务器重定向到“下一个”服务器，继续客户端搜索具有“权威来源”的服务器，最终声明权威地那这IP 地址是这目标“子区域域名”DNS 协议服务器的“主机域名”IP 地址。

“粘合记录”规定 IP 地址“桥接”非权威的源服务器最终权威性源服务器。客户端是否愿意验证当前服务器的 IP 地址是否与目标“子区域域名”的权威 DNS 名称服务器 IP 地址相匹配，由客户端自行决定。希望得到最好的结果 - 或者手动确认。可能完全不列出区域文件中的第一类自描述权威 NS 记录，并且仍然向客户端提供任何其他资源记录 - 只要客户端只是“希望得到最好的结果”并且实际上不检查 NS 记录及其关联的地址记录。

另请参阅 RFC 8499“DNS 术语”2019，https://www.rfc-editor.org/rfc/rfc8499.html。

什么是胶水记录？

答案1

答案2

答案3

答案4

相关内容