☰

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

tag-icon • tag-icon dns
DNS 名称解析原则上是如何工作的？

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

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

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

答案1

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

好吧，让我们把这个分开。

“假设您配置的名称服务器没有任何缓存结果可供使用”-- 首先，如果有的话不如果根本没有缓存数据，那么它就无法解决任何问题。为了填充解析器的缓存，您需要拥有.（AKA 根）区域的 NS 和地址（A、AAAA）记录。这是在区域中找到的根名称服务器root-servers.net.。该区域或那些 DNS 服务器并没有什么神奇之处。然而，这些数据通常是“带外”提供给 DNS 解析器的，正是为了填充解析器的缓存。仅限权威的名称服务器不需要此数据，但解析名称服务器需要。

另外，“决心”什么？该名称有任何 RRtype 吗？ RR A？或者是其他东西？什么类（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 A198.41.0.4 的 DNS 查询。它会告诉你“不，不会这样做，但这里有人可能知道”；这是一个转介。它包含NS相关服务器知道的最近区域的记录，以及服务器碰巧可用的任何粘合记录。如果没有可用的粘合数据，您首先必须解析您选择的 NS 记录中指定的主机，因此生成一个单独的名称解析来获取 IP 地址；如果粘合数据可用，您将获得至少“更接近”答案的名称服务器的 IP 地址。在本例中，这将是该区域的一组服务器com.，并且还提供粘合数据。

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

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

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

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

还值得记住的是，一些 RRtypes（特别是NS，MX以及其他一些；此外，A6已经相当好地使用了一段时间，但已被弃用）可以并且确实引用其他 RR。在这种情况下，您可能需要生成完后还有名称解析过程，为您的客户提供完整且有用的答复。

答案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。

相关内容