在 DNS 名称解析中，浏览器如何在众多 DNS 服务器中确定最近的可用 DNS 服务器？
我知道有 13 个根服务器，但是我的 ISP 的 DNS 服务器如何知道要联系哪个根 DNS 服务器？
答案1
您的浏览器不会。您的浏览器将使用标准系统调用来解析主机名（我相信通常是getaddrinfo()），而这些调用通常会依次检查的内容/etc/resolv.conf以查找已配置的解析名称服务器并对其进行查询。它们依次将您桌面操作系统的查询转发到上游服务器（缓存任何回复）或自己执行递归解析。请注意，上述链中的大多数步骤都是可配置的，因此您的浏览器实际上将本地确定；但上述场景是典型的。
该链中的递归解析名称服务器（无论是您本地配置的权威名称服务器，还是某些 ISP 的服务器）需要知道如何找到根服务器，并且它们通过预先配置的区域文件来执行此操作.（通常通过查询可用的根名称服务器定期更新）。
编辑：不是。它将依赖于实现，但就我的情况 (BIND) 而言，它只会选择一个并进行查询。只要它及时得到答案，它就会从那里向下递归。是什么让您认为任何类型的测距操作都在进行？
答案2
在 DNS 名称解析中，浏览器如何在众多 DNS 服务器中确定最近的可用 DNS 服务器？
正如其他答案所指出的，您的浏览器或其他客户端程序不会进行此选择。客户端程序通过调用称为解析器的库来请求名称服务解析。
解析器决定应联系哪些服务器来提出查询。这取决于解析器的实现，但通常它按顺序查阅已配置的递归解析器列表（通过静态配置或通过 DHCP 等机制接收它们）。
总而言之：您的（用户级）程序要求解析器进行名称解析，解析器询问通过某种配置机制提供给它的名称服务器。
我知道有 13 个根服务器，但是我的 ISP 的 DNS 服务器如何知道要联系哪个根 DNS 服务器？
这也取决于具体实现。我将描述它如何与 BIND 配合使用，因为
- BIND 是一个非常流行的名称服务器，您的 ISP 很有可能正在使用它，并且
- 即使您的 ISP 不使用 BIND，一些替代方案也会使用类似的机制从 NS 资源记录集中选择名称服务器。
首先，我们先来谈谈递归名称服务器如何知道从哪些名称服务器中选择与特定域进行通信。对于可从名称服务器的根（“.”）级别访问的每个域，管理该域的管理员在包含父域中发布记录类型为 NS（即名称服务器）的资源记录集，以公开委托资源记录集中指定的名称服务器负责解决与该域有关的查询。
该系统的优点之一是它允许对域名系统进行分布式层次化委托，并且是唯一需要递归服务器的域先验知识是根级别，服务器配置为了解该级别。过去最常见的方法是通过 BIND 启动时加载的“提示”文件为根指定 NS RRset，但现在根服务器使用的 IP 地址已在 BIND 中预先定义。[题外话：您仍然可以通过指定根提示区域来覆盖内置内容，事实上，d.root-servers.net 的地址最近发生了变化，新位置不会反映在内置列表中，直到构建和分发包含新信息的新版本的 BIND。目前，包含 D 根服务器新 IP 地址的版本处于测试阶段。]
无论如何，这里的关键点是每个域都与其关联一个 NS 记录 RRset，其中包含该域公开宣布的名称服务器。您应该自己尝试查看一些。让我们看看根：
$ dig . ns +edns=0 @f.root-servers.net.
我将只剪掉答案部分，它将包含以不可预测的顺序返回的 NS RRset（我在这里稍微掩饰一下——顺序通常由我正在交谈的名称服务器的配置决定。不同的根可能会以不同的顺序回答，但排序的项目应该相同。）
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
这些都是根域（“.”）的所有名称服务器，我们可以向其中任何一个询问有关根域的问题。如果我们向他们询问不在根域中的问题，我们会收到错误消息，或者更可能收到对另一组名称服务器的推荐（例如“example.com？我不回答有关 example.com 的问题。。尝试询问 .com 域名服务器 - 它们在那里。。”）
那么，BIND 如何知道 NS RRset 中的哪个名称服务器将为其提供最快的响应？
答案是：一开始它不会。但在它的默认行为下，它会随着时间的推移而学习，并适应通常询问往返时间最短的服务器。
往返时间和候选名称服务器的选择 BIND 依靠 RRset 中到名称服务器的往返时间 (RTT) 来选择哪个名称服务器应接收其查询。第一次将域的 NS RRset 添加到缓存中时，集合中的所有记录都会被分配一个较小的随机往返时间，大约为几毫秒。在初始准备之后，当需要将查询定向到为给定域委派的名称服务器时，BIND 将检查其缓存并（希望）找到 RRset。它从集合中选择具有最低 RTT 时间的服务器并进行查询。查询完成后，BIND 将按如下方式更新 NS RRset 的 RTT：
- 刚刚查询的服务器的 RTT 被设置为其实际往返时间。
- RRset 中的所有其他服务器的 RTT 都减少了一小部分（我认为约为 3-4%）。
让我们通过一个示例来了解其工作原理。我的递归解析器第一次遇到域 example.com 时，它会将 example.com 的 NS RRset 加载到其缓存中。假设 example.com 的管理员已宣布了 example.com 的三个名称服务器，因此 NS RRset 如下所示：
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
为了便于说明，我们还假设您的解析器需要以下时间才能从该集合中的每个服务器收到响应：
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
现在，第一次加载 example.com NS RRset 时，RTT 权重会用小的随机值作为基础。因此，在我们向 example.com 名称服务器询问任何内容之前，RTT 表可能如下所示：
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
第一次查询 example.com 时，我们将转到 serverc 并提出问题。Serverc 需要 50 毫秒才能响应，因此查询完成后，我们将更新 RTT 表，使其现在显示为：
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
下一次我们显然会选择 servera，因为它现在的往返时间最短。在对 example.com 域进行几次查询后，我们应该很清楚哪个名称服务器的响应速度最快，因此我们将优先选择该服务器最多的时间。
为什么最多而不是全部时间？我之前提到的“RRset 中的所有其他服务器的 RTT 都减少了一小部分”是怎么回事？好吧，事实证明，虽然我们想更喜欢最快的服务器，我们不想永久地放弃其他服务器。也许服务器 c 几乎一直都是最快的服务器，但在我们第一次设置它的 RTT 时，它异常繁忙。也许某个服务器暂时停止服务，导致 RTT 非常高（在我们尝试查询它超时之后），但我们希望在它恢复服务后再次开始询问它。通过每次向下调整其他服务器的值，它们迟早会低于我们首选服务器的平均 RTT。当这种情况发生时，我们会向它们发出查询，如果时间更合适，那就太好了。否则，我们会重置它的 RTT，它会回到优先级列表的底部，直到它再次回到前面。我们的大多数查询将转到集合中最快的服务器，但会定期尝试异常值，以确保如果条件发生变化，表格会更新以反映该情况，并且平均而言仍会选择最佳服务器。
答案3
13 个根域名服务器实际上并不是 13 个服务器。每个服务器都是位于世界各地不同站点的分布式服务器集群，它们通过标准 IP 路由进行访问，就像任何其他服务器一样。
至于哪个ISP 的 DNS 服务器选择联系的根名称服务器，这可能取决于其 DNS 解析器的详细信息。也许是完全随机的，也许是加权的，但我无法告诉你。
编辑：如果你的意思是，ISP 如何寻找13 个名称服务器中的任何一个，都有一个公共列表，其中列出了它们及其对应的 IP 地址，基本上每台计算机都有。从那里开始，只需选择一个，然后让互联网路由器完成其余的工作。