原则上，DNS名称解析如何工作？

现在，我正在上一门Linux系统管理员的在线课程，有人问我一个我通常不理解的问题。我知道如何搜索名称服务器，如果至少正确的话，它使用dig命令在其他section命令中查找地址，但是当被问到以下问题时，我有点迷路。

假设您配置的名称服务器没有任何缓存结果可供使用，那么您的名称服务器必须查询多少个名称服务器才能解析maps.google.com？您将使用什么命令来查找所有这些名称服务器？从每个级别列出一个，并说明为什么需要此级别。

我不想要答案，我只想知道我被要求做的是什么。

假设您配置的名称服务器没有任何缓存结果可供使用，那么您的名称服务器必须查询多少个名称服务器才能解析maps.google.com？您将使用什么命令来查找所有这些名称服务器？从每个级别列出一个，并说明为什么需要此级别。

好吧，让我们分开。

“假设您配置的名称服务器没有任何缓存结果可供使用” –首先，如果它根本没有缓存数据，那么它将无法解析任何内容。为了准备解析程序的缓存，您需要具有.（AKA根）区域的NS和地址（A，AAAA）记录。这就是在root-servers.net.区域中找到的根名称服务器。该区域或这些DNS服务器没有什么神奇的。但是，通常将这些数据“带外”提供给DNS解析器，以精确地填充解析器的缓存。仅权威的名称服务器不需要此数据，但解析名称服务器则需要此数据。

另外，“解决”要做什么？该名称有任何RRtype吗？一个ARR？或者是其他东西？什么类（CH/ Chaosnet，IN/ Internet等）？确切的过程将有所不同，但是总体思路保持不变。

如果可以假设我们知道如何找到根名称服务器，仅此而已，并且通过“解析”意味着获取IN A与该名称相关联的任何RR 的内容，那么它将变得更加实用。

要解析DNS名称，您基本上将名称拆分为标签，然后从右到左进行操作。不要忘记.最后的内容。你真的会解决maps.google.com.而不是解决maps.google.com。这使得我们需要解析（我们知道这一点，但是DNS解析器实现可能不会）：

• .
• com.
• google.com.
• maps.google.com.

首先弄清楚在哪里索要的内容.。这很容易; 我们已经有了该信息：根名称服务器名称和IP地址。因此，我们有一个根名称服务器。假设我们决定使用198.41.0.4（a.root-servers.net，也使用2001：503：ba3e :: 2：30）继续名称解析。在实践中，解析程序要做的第一件事之一可能是使用提供的根服务器数据向一台根区域服务器询问根区域名称服务器的准确列表，从而确保是否存在以下任何一种：名称和IP地址是有效且可访问的，解析开始时，它将为根区域提供完整的数据集。

启动DNS查询以maps.google.com. IN A获取198.41.0.4。它会告诉您“不，不愿意，但是这里可能有人知道”。那是推荐。它包含NS有关服务器已知的最近区域的记录，以及服务器碰巧可用的所有粘合记录。如果没有可用的粘合数据，则首先必须解析所选NS记录中命名的主机，因此请生成单独的名称解析以获取IP地址。如果有粘合数据可用，您将拥有一个名称服务器的IP地址，该IP地址至少“接近”答案。在这种情况下，这将是该com.区域的服务器集，并且还将提供粘合数据。

重复此过程，向其中一个com.名称服务器询问相同的问题。他们都不知道，但是会将您引到Google的权威名称服务器。此时，在一般情况下，是否提供胶水数据会很容易出错。例如，没有什么可以阻止com域名仅nl在其中拥有名称服务器的情况，在这种情况下，不太可能从gTLD服务器获得胶粘数据。提供的粘合数据也可能不完整，或者如果您真的不走运，甚至可能不正确！您必须时刻准备着产生上面提到的单独的名称解析。

基本上，您会一直努力直到获得aa设置了（权威答案）标志的答案。该答案将告诉您您要的是什么，或者您所要求的RR不存在（或NXDOMAIN，或者NOERROR响应数据记录为零）。继续寻找类似的响应SERVFAIL（如果有，则退后一步，然后尝试另一台服务器；如果所有命名服务器都返回SERVFAIL，则名称解析过程将失败，并将SERVFAIL自己返回给客户端）。

从每个服务器要求完整的RR名称的方法（这可能被认为是不正确的做法），是使用我们之前确定的标签拆分列表，向该/ IN NS和RR 的根目录进一步询问服务器提供的名称服务器标签，并使用它们来进一步进行名称解析过程。在实践中，这仅稍有不同，并且仍然适用相同的过程。IN AIN AAAA

您可以使用BIND或中附带+trace的dig实用程序选项来模拟整个过程。set debugnslookup

还值得记住的是，某些RR类型（尤其是NS，MX还有其他一些；也A6被合理使用了一段时间，但已被弃用）可以并且确实引用了其他RR。在这种情况下，您可能需要启动另一个名称解析过程，才能向客户提供完整而有用的回复。

有一个dnstracer命令（至少在Debian上需要安装它，这也是软件包名称），该命令将跟踪名称解析。您也可以（如Koveras在评论中指出）使用dig。

这是dnstracer。-s .指从根开始；-4使用IPv4的方式（此处v6已损坏...）；-o表示实际上在末尾显示解析的IP地址（我省略了输出的那一部分，其中有很多）。

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

随着dnstracer跟踪所有路径，该输出将继续（例如，您可以查看某些名称服务器是否具有过时的区域）。

因此，您可以看到它首先查询根名称服务器，然后查询gtld服务器（.com区域的服务器），最后查询一个Google名称服务器。

使用dig，输出更加冗长（因此，我将进行很多裁剪）：

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

dig另外显示它进行了查询以获得当前的根名称服务器列表。这是DNS服务器通常很少执行的操作。因此，我不确定您是否将其计入冷缓存情况。

当然，您也可以使用观看在线上的实际查询wireshark。