在本文的第一部分 [LJ，2008 年 1 月] 中，我们开始了看似简单的旅程，通过遍历 DNS 层级结构来导航到 www.example.com 和其安全服务器 online.example.com 的 IP 地址。我们最终从 gTLD .com 服务器收到了一个引用，指向名称服务器 ns2.example.com（区域内名称服务器）和 ns1.example.net（区域外或保税区外名称服务器）。

那么，让我们重新开始寻找 www.example.com 的 IP 地址，并假设我们已经验证并获得了 ns1.example.net 的 IP 地址，因为它在区域外，我们通过 .net gTLD 服务器将其追踪到其权威来源。现在，是时候检查我们 example.com 域的所有权威服务器，看看我们还能找到什么。首先，我们检查前门

dig @ns1.example.net version.bind txt ch

此命令使用称为 CH(AOS) 的旧版 DNS 资源记录类（Internet 地址使用 IN 类）来尝试获取有关正在使用的软件的信息。我们得到以下响应

; <<>> DiG 9.4.1-P1 <<>> @ns1.example.net version.bind txt ch

...

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8503

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;version.bind. CH TXT


;; ANSWER SECTION:

VERSION.BIND. 0 CH TXT "named 4.9.6-Rel-Tuesday-24-June-97..."


;; Query time: 25 msec

;; SERVER: 207.253.126.250#53(207.253.126.250)

...

而且，我们很幸运。此名称服务器正在告诉我们其软件的供应商和版本号。如果我们是坏人，我们会去查找此版本软件的警报，看看是否有任何有价值的漏洞。在这种情况下，对于坏人来说，消息非常棒，因为服务器正在运行 BIND 4，最后一次更新是在 1997 年！估计仍在运行的 900 万个名称服务器中，有 3% 到 7% 仍在使用这个冗余软件，它充满了错误和可利用的可能性。让我们假设我们重复该命令，替换为 ns2.example.com（我们的第二个权威服务器），我们得到回复“my name is Bind, James Bind”。此 DNS 的管理员很有幽默感，并且对 BIND 配置参数有所了解。在 BIND 的 named.conf 文件（通常位于 /etc/named.conf 中）的 options 子句中，将出现以下参数

options {

...

version "my name is Bind, James Bind";

...

}

您可以将任何文本放在此处，它将代替版本号提供。如果缺少该语句，BIND 将返回其版本号，如上一个示例所示。正如我们将看到的，这可能无法阻止我们发现信息，但至少它使其不仅仅是一行简单的命令。最后，虽然 BIND 服务器响应上述命令，但并非所有 DNS 软件都这样做，因此我们可能会收到超时。

现在，是时候进行下一个检查了。我们将使用我们的第二个工具 fpdns，它是一个 DNS 指纹识别工具（有关 fpdns 的更多信息，请参见本文的第一部分）。fpdns 使用一系列良性技术来尝试识别软件供应商，并在许多情况下识别发布版本或版本范围。它并非万无一失，但其准确性非常高。让我们用它来检查我们不情愿的 Bind 先生

fpdns ns2.example.com

我们得到以下结果

fingerprint (ns2.example.com, 10.10.0.2): ISC BIND 9.2.0rc7 -- 9.2.2-P3
[recursion enabled] 

现在，这也可能很严重。首先，在撰写本文时，BIND 的当前版本是 9.4.1-P1。因此，我们可以简单地检查引用的版本范围的安全警报，看看我们是否有一些方便的投毒可能性。其次，此服务器是一个开放递归服务器，这意味着此服务器将接受并处理任何名称解析请求，而不仅仅是它具有权威性的名称。我们可以使用如下所示的 dig 命令来测试它

dig @ns2.example.com some.obscure.domain

为什么开放解析器是一个严重的问题？有三个原因。首先，我们可以通过向其发送外部名称解析请求来加载服务器以进行简单的拒绝服务 (DoS) 攻击。它会忙于跟踪引用链，以至于没有时间回答对其具有权威性的域的请求——有效地使该域至少有一部分流量离线。其次，它可用于分布式拒绝服务攻击。在这种类型的攻击中，向许多开放名称服务器（互联网上可能有大约一百万个开放名称服务器）发送对同一名称的请求，每个服务器然后向 DoS 目标发送查询。没有一个单独的请求会突破任何阈值监控，因此很难识别所有来源。最终效果是目标 DNS 受到流量轰炸，无法响应。第三，如果我向开放名称服务器发送查询，我知道它将要做什么；它将向目标域的名称服务器发送查询。因此，即使不监听其流量，我也可以开始发送欺骗响应，如果我幸运的话，我可以毒害开放服务器的缓存（有许多已记录的弱点，我可以利用这些弱点来显着增加我的机会）。

缓存服务器的功能是保存响应，直到资源记录的 TTL（生存时间）到期，然后重新读取记录。如果请求的 RR 的 TTL 很长（30 分钟或更长时间），我每 30 分钟或更长时间才有一次投毒机会，但如果 TTL 很短，例如 5 秒甚至 0 秒，我将中毒响应放入缓存的几率会急剧上升。当然，我的中毒响应不会有 5 秒的 TTL；它更像是 5 周，所以当它在那里时，它会在那里停留很长时间。

现在，进行此缓存投毒的真正场所不是权威名称服务器。相反，我会去 ISP 寻找开放递归名称服务器，并尝试使用相同的技术毒害缓存，以便 ISP 的所有 www.example.com 客户端都将访问我的网络钓鱼站点。

所有名称服务器都应关闭外部流量以阻止此行为。如果您正在使用 BIND，则有三个选项

1) 如果名称服务器仅是权威的（最佳实践建议您永远不要在同一 DNS 中混合缓存和权威功能），请将以下行添加到 options 子句中的 /etc/named.conf 文件中

options {

...

// BIND's default is recursion yes;

recursion no;

...

};

2) 如果您的服务器确实提供权威和递归服务，请使用 options 子句中的 allow-recursion 语句来限制谁可以使用它们

options {

...

allow-recursion {192.168.2/24};

...

};

此语句将允许进行递归请求的允许 IP 地址限制为 192.168.2.1–192.168.2.254。值得指出的是，即使存在此语句，如果缓存中已存在来自定义 IP 范围之外的递归请求（先前由有效的内部用户请求），它仍将返回正确的结果。BIND 9 的 view 子句也可用于在混合权威和缓存配置中提供进一步的控制和分离。

3) 最后，如果服务器仅提供缓存服务，请改用 allow-query 语句

options {

...

allow-query {192.168.2/24};

};

现在，让我们继续我们的检查，从其权威服务器之一请求我们目标的 IP 地址

dig @ns1.example.net www.example.com

我们得到以下响应

; <<>> DiG 9.4.1-P1 <<>> @ns1.example.net www.example.com

...

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49319

;; flags: qr rd ra aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:

;www.example.net. IN A


;; ANSWER SECTION:

www.example.com. 5 IN A 10.10.0.5

www.example.com. 5 IN A 10.10.0.6

;; Query time: 61 msec

;; SERVER: 192.5.6.30#53(192.5.6.30)

...

在此响应中有几点需要注意。首先，设置了 aa 标志，这是我们所期望的。如果未设置此标志，则这将被称为 lame-server（在父项中定义为域的权威服务器，但不向该域中信息的查询返回 aa 标志的服务器）。域的主（主）和从（辅助）名称服务器必须返回 aa 标志。主服务器和从服务器响应之间没有外部可见的差异。这意味着您可以使用两个或多个从服务器来提供权威服务，并使您的主服务器完全隐藏。需要注意的第二点是设置了 ra 标志，从而提供递归服务。让我们测试一下

dig @dns1.example.net some.obscure.domain

宾果，我们得到了响应——此服务器也是开放的。使用 some.obscure.domain 的原因是确保数据尚未缓存，在这种情况下，根据其配置，名称服务器可能会返回所需的结果，并且仍然像之前指出的那样是关闭的。使用模糊名称可以最大限度地减少误报的可能性。推论也是如此。如果我们向看似关闭的 DNS 发送对流行域名（例如 google.com）的请求并获得有效结果，我们知道此服务器正在为某些客户端集提供递归服务——除非它当然是 google.com 的权威服务器！此知识为我们提供了一些非常适度的中毒可能性，方法是查看响应的 TTL 时间。

顺便说一句，我们还应该注意到，该站点明智地提供了两个 IP 地址，尽管它们都在同一个 IP 地址块上。这意味着浏览器将自动故障转移（在 2-3 分钟内）。如果第一个服务器失败，它使用 5 秒的 TTL，除了对潜在的缓存投毒者有很大帮助之外，它完全无用，因为 Microsoft 的浏览器仅每 30 分钟（Firefox 为 1 分钟）尝试刷新其浏览器缓存的 IP 地址。

因此，ns1.example.net 正在使用旧的、有漏洞的软件并且是开放的。情况会更糟吗？好吧，是的，会更糟，而且实际上，在这种情况下，情况确实变得更糟。

到目前为止，我们一直在模拟浏览器的行为，只是在寻找 ARR；dig 可用于查找任何类型的 RR。在这种情况下，缺少 AUTHORITY SECTION 有点可疑，所以让我们尝试一下这个命令

dig @ns1.example.net www.example.com ns

我们得到以下响应

; <<>> DiG 9.4.1-P1 <<>> @ns1.example.net www.example.com ns

...

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49319

;; flags: qr rd ra aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:

;www.example.com. IN NS



;; ANSWER SECTION:

www.example.com. 3000 IN NS ns3.example.com.

www.example.com. 3000 IN NS ns4.example.com.


;; ADDITIONAL SECTION:

ns3.example.com. 3000 IN A 10.10.0.8

ns3.example.com. 3000 IN A 10.10.0.9


;; Query time: 61 msec

;; SERVER: 192.5.6.30#53(192.5.6.30)

...

此结果意味着用户正在尝试将 www.example.com 委派给另一组 DNS 服务器 ns3 和 ns4.example.com，但委派无效，因此定义的 DNS 服务器不可见。区域文件可能具有以下构造

$ORIGIN example.com.

...

; these A RRs should not be present in the example.com

; zone file but should be present in a www.example.com zone file

www 5 IN A 10.10.0.5

www 5 IN A 10.10.0.5

; valid delegation for www.example.com

www 3000 IN NS ns3.example.com.

www 3000 IN NS ns4.example.com.

...

; required glue RRs for the delegation

ns3.example.com. 3000 IN A 10.10.0.8

ns3.example.com. 3000 IN A 10.10.0.9

BIND 9（由 ns2.example.com 使用）将正确地将其解释为委派，并生成对 ns3 和 ns4.example.com 的引用。BIND 4 (ns1.example.net) 则不会，因此，大约 50% 的流量甚至永远不会看到委派的服务器，如果我们使用上述技术执行检查，我们将看到这些服务器配置稳固并且正在使用最新版本的 BIND（与 online.example.com 的名称服务器类似）。

总而言之，该用户非常谨慎和专业地配置和维护了他的内部名称服务器，但完全忽略了用户到达该站点的路线。换句话说，城堡坚不可摧，护城河又宽又深，城墙厚实，防御坚固，但前门却大开。

这个问题可能看起来很牵强，但它是真实的，不到十分钟就找到了，而且——以防您想知道——现在已经修复了！

在执行此类分析时，您将开发自己的方法和变体，但以下是一些似乎使组织特别容易受到攻击的事项

此处使用的技术并不具有攻击性；例如，它们不测试 AXFR（区域传输）漏洞，因为这不是友好的行为，并且很可能（理所当然地）会从 DNS 管理员那里产生令人讨厌的响应。轻踩是最好的技术。

我们在此处使用了 dig 功能的一个非常小的子集。阅读手册页以获取更多信息。如果您确实发现任何可疑或错误之处，请仔细检查，然后立即修复它，或者，如果它影响到第三方，请负责任地采取行动并通知相关组织（尽管有时非常难以联系到合适的人）。从理论上讲，相关域的 SOA RR 应包含组织中合适人员的有效电子邮件地址。

我鼓励您尝试并修改诊断和审核 DNS 系统的技术——它将一次又一次地获得回报——最好您在坏人之前到达那里。而且，当您四处侦查时，它可以提供无尽的乐趣。