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

Question

现在我正在参加 Linux 系统管理员的在线课程，有人问我一个我通常不明白的问题。我知道如何搜索名称服务器，如果我是正确的，至少它使用 dig 命令来查找附加部分命令中的地址，但是当被问到以下问题时，我有点迷茫。

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

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

Answer 1

假设您配置的域名服务器没有任何缓存结果可供使用，您的域名服务器必须查询多少个域名服务器才能解析 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 地址是有效且可访问的，当解析开始时，它将拥有完整的根区域数据集。

maps.google.com. IN A向 198.41.0.4 发起DNS 查询。它会告诉你“不，不会这样做，但有人可能知道”；那是转介。它包含有NS问题的服务器知道的最近区域的记录，以及服务器碰巧可用的任何粘合记录。如果没有可用的粘合数据，您首先必须解析在您选择的 NS 记录中命名的主机，因此生成一个单独的名称解析来获取 IP 地址；如果胶水数据可用，您将拥有至少“更接近”答案的名称服务器的 IP 地址。在这种情况下，这将是该com.区域的一组服务器，并且还提供了胶水数据。

重复该过程，向其中一个com.名称服务器询问相同的问题。他们也不知道，但会将您推荐给 Google 的权威名称服务器。此时在一般情况下，无论是否提供胶水数据都会被击中或错过；例如，没有什么可以阻止com域仅在nl. 提供的胶水数据也可能不完整，或者如果您真的不走运，它甚至可能不正确！您必须始终准备好产生我上面提到的那个单独的名称解析。

基本上，您会一直进行下去，直到得到带有aa（权威答案）标志集的答案。该答案将告诉您您要求什么，或者您要求的 RR 不存在（或者NXDOMAIN，或NOERROR具有零响应数据记录）。继续寻找像这样的响应SERVFAIL（如果你得到一个，则退后一步并尝试另一台服务器；如果所有命名服务器都返回SERVFAIL，则名称解析过程失败并将SERVFAIL自己返回给客户端）。

向每个服务器询问完整的 RR 名称（这可能被认为是不好的做法）的替代方法是使用我们之前确定的拆分标签列表，向服务器提供的名称服务器进一步向根请求IN NS和IN A/ IN AAAARR用于该标签，并使用它们来进一步进行名称解析过程。这在实践中只是略有不同，同样的过程仍然适用。

您可以使用该实用程序的+trace选项来模拟整个过程，该选项dig作为 BIND 的一部分提供，或set debug在nslookup.

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

Answer 2

有一个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-servers（.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。