当我发出 DNS 请求时my.example.net，我的 DNS 递归服务器会转到 DNS 根区域（或获取一些缓存值）。该名称服务器说“去查看名称.net服务器”，而这些名称服务器又说“查看example.net名称服务器”，而这些名称服务器又说“my.example.net位于xxx.xxx.xxx.xxx”。
维基百科说“委派中的名称服务器是通过名称而不是 IP 地址来标识的”，并且胶水记录支持这一点。
问题 1:
我不明白 DNS 根区域告诉我去哪里a.gtld-servers.net（或任何 .net 名称服务器）进行解析my.example.net有什么帮助，因为.net名称服务器中有.netIP 地址，而我没有 IP 地址。它只是 TLD 级别的粘合记录吗？
问题2：
如果粘合记录是 DNS 的必需部分，那么为什么委派是通过主机名而不是 IP 地址进行的？
答案1
运行递归解析器（例如 Google 使用 8.8.8.8，或您的 ISP）的人需要提供至少一个根服务器的 IP 地址 - 通常通过提示文件提供。根服务器的 IP 是由 IANA 记录并且很少改变。
使非根 DNS 服务器更容易更改 IP、拥有多个 IP、或为不同的区域提供不同的 IP 等。
答案2
所有递归名称服务器软件都附带当前根名称服务器及其 IP 地址的列表。
这提供了一个基础，因为这种情况可以改变，但速度很慢。
启动后，服务器将连接上述任意 IP 地址，通过. NSDNS 查询检索当前的根名称服务器列表，然后更新其内部列表并将其用于所有进一步的需求。此过程称为“启动”。
如果你想要详细信息，请阅读RFC 8109“使用启动查询初始化 DNS 解析器”
至于您关于胶合的问题，请记住胶合是一种特殊的边缘情况。如果您使用域名，adomain.example则ns1.anotherdomain.test任何地方都没有胶合记录。请参阅此有关 DNS 术语的新文档中“胶合记录”的定义：https://www.rfc-editor.org/rfc/rfc7719#section-6：
粘合记录：“[资源记录] 不属于 [区域] 权威数据，而是 [子区域中的名称服务器] 的地址资源记录。只有当名称服务器的名称‘低于’截止值时，这些 RR 才是必要的，并且仅用作引荐响应的一部分。”如果没有粘合，“我们可能会面临这样的情况：NS RR 告诉我们，为了了解名称服务器的地址，我们应该使用我们希望了解的地址联系服务器。”（定义来自 [RFC1034]，第 4.2.1 节）
至于“当我向 my.example.net 发出 DNS 请求时，它会转到 DNS 根区域”，不，这不是真的。您的系统使用一个（或多个）递归 DNS 服务器，无论是本地的还是公共的。您将所有 DNS 查询发送给它们。正如它们的名称所暗示的那样，如果它们当前的缓存没有数据来回复您的查询，它们将负责以递归方式从根开始对多个名称服务器进行迭代查询。
因此，让我们用真实姓名举例说明，例如www.stackexchange.com。
您可以执行dig +trace www.stackexchange.com A此操作来查看究竟发生了什么，+trace触发完整递归模式并显示任何递归名称服务器在其缓存为空时执行的操作。
但我们可以手动重做。如果你想遵循特定的算法，请阅读“4.3.2. 算法”RFC 1034 域名 - 概念和设施（但请注意，后来又增加了一些内容，特别是针对 DNSSEC 和其他记录，如 DNAME）
例如https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/rootns.c
这是 BIND 源代码的一部分。但它基本上是带有 IP 地址的回复内容. NS，即当前的根名称服务器列表及其 IPv4 和 IPv6 地址。
我们在这里忽略 DNS 启动步骤（更新以上列表）
步骤1
选择上述 IP 地址之一并执行查询：
$ dig @192.112.36.4 www.stackexchange.com A +nodnssec
; <<>> DiG 9.12.0 <<>> @192.112.36.4 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59725
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59725
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; AUTHORITY SECTION:
com. 2d IN NS k.gtld-servers.net.
com. 2d IN NS e.gtld-servers.net.
com. 2d IN NS g.gtld-servers.net.
com. 2d IN NS c.gtld-servers.net.
com. 2d IN NS l.gtld-servers.net.
com. 2d IN NS j.gtld-servers.net.
com. 2d IN NS h.gtld-servers.net.
com. 2d IN NS a.gtld-servers.net.
com. 2d IN NS b.gtld-servers.net.
com. 2d IN NS m.gtld-servers.net.
com. 2d IN NS d.gtld-servers.net.
com. 2d IN NS f.gtld-servers.net.
com. 2d IN NS i.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 2d IN A 192.5.6.30
b.gtld-servers.net. 2d IN A 192.33.14.30
c.gtld-servers.net. 2d IN A 192.26.92.30
d.gtld-servers.net. 2d IN A 192.31.80.30
e.gtld-servers.net. 2d IN A 192.12.94.30
f.gtld-servers.net. 2d IN A 192.35.51.30
g.gtld-servers.net. 2d IN A 192.42.93.30
h.gtld-servers.net. 2d IN A 192.54.112.30
i.gtld-servers.net. 2d IN A 192.43.172.30
j.gtld-servers.net. 2d IN A 192.48.79.30
k.gtld-servers.net. 2d IN A 192.52.178.30
l.gtld-servers.net. 2d IN A 192.41.162.30
m.gtld-servers.net. 2d IN A 192.55.83.30
a.gtld-servers.net. 2d IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 2d IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 2d IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 2d IN AAAA 2001:500:856e::30
e.gtld-servers.net. 2d IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 2d IN AAAA 2001:503:d414::30
g.gtld-servers.net. 2d IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 2d IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 2d IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 2d IN AAAA 2001:502:7094::30
k.gtld-servers.net. 2d IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 2d IN AAAA 2001:500:d937::30
m.gtld-servers.net. 2d IN AAAA 2001:501:b1f9::30
;; Query time: 121 msec
;; SERVER: 192.112.36.4#53(192.112.36.4)
;; WHEN: Tue Mar 26 12:22:23 EST 2019
;; MSG SIZE rcvd: 874
因此服务器192.112.36.4正在回复我们：
NOERROR：我们的请求是有效的- 没有
aa标记，我们没有得到权威的答复，只是给出了下一步该怎么做的指示 - “警告：请求递归但不可用”：正如预期的那样，
.我们查询的权威名称服务器没有为我们执行递归 - 因此，该服务器知道，为了帮助我们的请求，只有 上的权威名称服务器
.COM才能提供它们的名称和 IP 地址。
现在，递归名称服务器没有义务信任“附加部分”的内容。它可以再次使用，m.gtld-servers.net.例如，并向相同的权威名称服务器询问。同样，它将返回它对此名称不具有权威性但知道名称服务器的数据，.NET并返回它们的名称和 IP 地址。在这里，由于它们的名称再次全部为.NET，因此它们属于管辖范围，并且服务器必须信任提供的 IP 地址。
第2步
选择上述任意一个 IP 地址，我们再次进行查询：
$ 挖@192.26.92.30www.stackexchange.com答：
; <<>> DiG 9.12.0 <<>> @192.26.92.30 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45273
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45273
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; AUTHORITY SECTION:
stackexchange.com. 2d IN NS ns-925.awsdns-51.net.
stackexchange.com. 2d IN NS ns-1029.awsdns-00.org.
stackexchange.com. 2d IN NS ns-cloud-d1.googledomains.com.
stackexchange.com. 2d IN NS ns-cloud-d2.googledomains.com.
;; ADDITIONAL SECTION:
ns-cloud-d1.googledomains.com. 2d IN AAAA 2001:4860:4802:32::6d
ns-cloud-d1.googledomains.com. 2d IN A 216.239.32.109
ns-cloud-d2.googledomains.com. 2d IN AAAA 2001:4860:4802:34::6d
ns-cloud-d2.googledomains.com. 2d IN A 216.239.34.109
;; Query time: 108 msec
;; SERVER: 192.26.92.30#53(192.26.92.30)
;; WHEN: Tue Mar 26 12:35:56 EST 2019
;; MSG SIZE rcvd: 273
这里的服务器为192.26.92.30我们提供的答案与之前大致相同：它对于我们所寻找的名称没有权威性，但提供了其名称服务器和 IP 地址。
同样，namserver 无法请求名称ns-cloud-d1.googledomains.com.，但名称显然来自同一个 namserver，与同一个 TLD 相同，因此它可以使用上述 IP 地址。或者它可以再次从头开始解析名称ns-925.awsdns-51.net.或区域ns-1029.awsdns-00.org.外部的名称.COM，因此不提供 IP 地址。
步骤3
因此，为了简化使用上述 IP 地址之一并重新进行查询：
$ dig @216.239.34.109 www.stackexchange.com A +nodnssec
; <<>> DiG 9.12.0 <<>> @216.239.34.109 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16720
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16720
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; ANSWER SECTION:
www.stackexchange.com. 5m IN CNAME stackexchange.com.
stackexchange.com. 5m IN A 151.101.1.69
stackexchange.com. 5m IN A 151.101.65.69
stackexchange.com. 5m IN A 151.101.129.69
stackexchange.com. 5m IN A 151.101.193.69
;; Query time: 149 msec
;; SERVER: 216.239.34.109#53(216.239.34.109)
;; WHEN: Tue Mar 26 12:38:34 EST 2019
;; MSG SIZE rcvd: 128
请注意一个重要的区别：AA 标志，表示我们刚刚查询的名称服务器确实对我们查询的名称具有权威性，因此其结果是“最终的”。事实上，它表明我们的名称是一种CNAME记录类型，但它确实提供了目标的 IP 地址，所以我们的查询已经完成，我们现在能够解决这个问题，www.stackexchange.com而从哪里完成的，是 IP 地址151.101.1.69和151.101.65.69和151.101.129.69和151.101.193.69。