当在 NS 记录中找到权威服务器时，是否会检查 A 记录中的 IP 地址？

Question

我试图了解什么是 NS 记录，粘合记录如何构成它的一部分以及之后会发生什么？

胶水记录不属于NS记录的一部分。

粘合记录或胶水是A和AAAA记录，唯一的不同之处在于它们是在代表团的父方发布的，而不是（实际上是另外）在权威方（代表团的子方）发布的。

您的大多数问题都很难回答，因为您没有使用具体示例。事情很大程度上取决于使用权威或递归名称服务器进行查询，因此不清楚您在做什么。

1.) 递归器如何知道 NS 记录是否指向权威名称服务器或将递归器引导至另一个名称服务器？

NS记录总是指向权威的名称服务器，这是它们的定义。

RFC 1034 §3.6：

            NS
           the authoritative name server for the domain

（当然，客户端无法检查这是否属实，因为如果没有 DNSSEC，这可能会在路径中或由您查询的递归解析器更改）。

我的意思是 NS 记录中的条目只是“尽力而为”的名称服务器

不，我不知道您从哪里得到“尽力而为”的说法，但NS记录是权威的名称服务器，仅此而已。

2.) 一旦递归器在特定名称服务器（例如 TLD 名称服务器）中的 NS 记录中找到条目，它是否会检查 A 记录以查找相应的 IP 地址，或者是否会再次重复整个 DNS 过程（查询根名称服务器，然后查询 TLD 名称服务器等）？

记录NS给出了一个名称。该名称需要解析为一个或多个 IPv4 或 IPv6 地址，因此任何用户（客户端）都需要将该名称解析为 IP，这通过与其他任何操作完全相同的机制进行，当然，缓存在那里被大量使用（因此主要名称服务器名称在世界各地的缓存中，并被许多域使用，因此它们的 IP 经常不被解析）。所以，是的，它从根开始……当然，除非存在胶水，以及它们可以被接受。

3.) “粘合”究竟是如何工作的，我知道它与避免递归查询有关，但粘合 IP 地址是否在 A 记录中找到？如果没有粘合，是否意味着对于 2.) 整个 DNS 过程将针对该主机名重新开始（我猜是来自 NS 记录）？

很简单。假设您有example.com一个域，它是从委派的com。因此，.com名称服务器具有指向其名称服务器的NS记录example.com。现在假设您选择“辖区内”情况，其中域名服务器本身位于域“之下”，即名称服务器是ns1.example.com和ns2.example.com。这些将是NS父级的记录。但是，有了所有这些，解析是不可能的。您询问父级“谁负责（权威）example.com”，然后您返回“联系人ns1.example.com和ns2.example.com”，但要做到这一点，您需要解析这两个名称，因此，再次从根开始，您又回到“谁负责（权威）example.com”，如此循环往复。

在这种情况下，需要有粘合剂，也就是父级的A/AAAA记录，客户端在收到回复的同时也会收到它NS。

让我们举一个真实的例子，带有现在的痕迹，即域icann.org。

首先，什么是.org名称服务器？

$ dig org. NS +short
c0.org.afilias-nst.info.
d0.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
a0.org.afilias-nst.info.

让我们选择其中任何一个并要求提供NS以下记录icann.org：

$ dig @b2.org.afilias-nst.org. icann.org NS

; <<>> DiG 9.18.4 <<>> @b2.org.afilias-nst.org. icann.org NS
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62392
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 4c1ae1af0f0d1e3f
;; QUESTION SECTION:
;icann.org.     IN NS

;; QUERY SIZE: 50

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62392
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;icann.org.     IN NS

;; AUTHORITY SECTION:
icann.org.      1h IN NS a.icann-servers.net.
icann.org.      1h IN NS b.icann-servers.net.
icann.org.      1h IN NS c.icann-servers.net.
icann.org.      1h IN NS ns.icann.org.

;; ADDITIONAL SECTION:
ns.icann.org.       1h IN A 199.4.138.53
ns.icann.org.       1h IN AAAA 2001:500:89::53

正如预期的那样，该AUTHORITY部分为您提供了记录列表NS。但这里有一个ADDITIONAL部分。为什么？因为的 4 个名称服务器之一icann.org是ns.icann.org，所以它属于管辖范围。为了能够解析它，父级（.org名称服务器）也必须发布胶水，即A/AAAA记录...并且它们位于该ADDITIONAL部分中，因此客户端现在可以ns.icann.org立即联系而无需进一步的 DNS 查询，因为它已经有了 IP 地址。

看到这些，你可能会想，为什么不每个人都只使用胶水而不使用其他东西，因为它看起来“更好”（更快、没有依赖性等）？事实上，它并不是更好，它有优点也有缺点（这就是为什么在大多数情况下，一个好的域名会使用一些辖区内的名称服务器和一些辖区外的名称服务器）。缺点包括：

IP 地址必须在注册机构进行管理；如果 IP 地址发生变化，则需要由域名注册商代表客户进行更改（在 DNS 之外，通常使用 EPP）；这一点经常被遗忘，并造成很多问题
即使icann.org完全启用了 DNSSEC，权威名称服务器的回复.org也不会对该部分中的记录进行签名ADDITIONAL，这意味着它们可以在路径上进行更改而不会被检测到

4.) 在 Cloudfare 对 NS 记录的解释中，示例包括一个 @，并且我也在这个示例区域 DNS、示例区域文件中看到了它，@ 或将该列留空实际上是什么意思？

两者实际上都不是 DNS 的一部分，而是称为“主区域文件格式”的约定，在 RFC1035 的 §5 中有松散的定义：

最后两种形式代表 RR。如果 RR 的条目以空白开头，则假定该 RR 归最后声明的所有者所有。

和

@ 独立的 @ 用于表示当前原点。

这只是意味着，如果您正在为任何记录的区域编写区域文件，example.com您可以写入example.com.（这里最后一个点非常重要，如果您忘记了它，它表示相对，因此example.com此文件中的名称实际上表示example.com.example.com.）或@它是同一件事，因此由您决定选择哪个。为什么它有用？因为对于某些通用区域，您可以为多个区域拥有完全相同的区域内容。如果您用区域内容编写区域内容，@因此不必在区域文件中写下区域名称，您可以将同一个文件重复用于多个区域，从而简化维护。

至于“将该列留空”，这也是一个您可以使用或不使用的快捷方式。

下面两个是一样的：

foobar IN A 192.0.2.42
foobar IN TXT "I am foobar"

和

foobar IN A 192.0.2.42
       IN TXT "I am foobar"

（空格量只是为了对齐，除了至少一个之外不需要特定数量）

甚至：

foobar IN TXT "I am foobar"
 IN A 192.0.2.42

在第二种情况下，需要写的内容较少，但缺点是您不能再轻松地移动行，因为第二行需要第一行的上下文。

这是第一个名称服务器 (bind) 的实现细节，描述了区域内容如何写入所谓的文本区域文件中。其他名称服务器必须遵循该约定并支持相同的格式。

但您永远不会对空名称进行 DNS 查询@（这种情况根本不可能）。因此，所有这些都隐藏在名称服务器中。

Answer 1