识别 DNS​​ 数据包

Posted 2023-04-15

【中文标题】识别 DNS​​ 数据包

【英文标题】：Identifying DNS packets

【发布时间】：2011-11-25 18:57:18

【问题描述】：

在查看数据包字节码时，您将如何识别 dns 数据包。 IP 标头的协议字段会告诉后面有一个 UDP 帧，但是在 UDP 帧内没有协议字段来指定接下来会发生什么，据我所见，帧内没有任何内容可以唯一地将其识别为 dns 数据包.

【参考方案1】：

除了它位于端口 53 之外，您还需要注意一些可能会提示您正在查看 DNS 流量的提示。

我会在这里大量引用RFC 1035 §4.1 中使用的字段名称：

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

正如您在上面看到的，标题有 12 个字节长 - 一个 2 个字节的 ID、2 个字节的标志和 4 x 2 个字节的计数。

在任何 DNS 数据包中，QDCOUNT 字段将恰好为 1 (0x0001)。从技术上讲，协议允许使用其他值，但实际上它们从未使用过。

在查询 (QR == 0) 中，ANCOUNT 和 NSCOUNT 值将完全为零 (0x0000)，ARCOUNT 通常为 0、1 或 2，具体取决于 @987654333正在使用@(RFC 2671)和TSIG(RFC 2845)。 RCODE 在查询中也将为零。

除非您同时观察对话的双方并且可以将每个响应与触发它的查询相关联，否则响应有点难以识别。

显然QR 位将被设置，并且如上所述QDCOUNT 仍应为1。然而，其余的计数器将有许多不同的排列。但是，极不可能有任何计数器大于 255，因此您应该能够依赖字节 4、6、8 和 10 都为零。

在标题之后，您将开始查找资源记录，第一个是所提出的实际问题（第 4.1.2 节）。不幸的是，协议的设计者认为在两个固定字段（QTYPE 和 QCLASS）前面包含一个可变长度标签字段（QNAME）是合适的。 p>

[为了使事情更复杂，标签可以被压缩，使用一个向后指针指向数据包中的其他地方。幸运的是，您几乎不会在问题部分看到压缩标签，因为根据定义，您不能从那里倒退。从技术上讲，不正当的实现者可以将压缩指针发送回标头，但这不应该发生]。

因此，开始读取每个长度字节，然后跳过那么多字节，直到达到空字节，然后接下来的两个 16 位字将是 QTYPE 和 QCLASS。 QCLASS 的 legal values 很少，几乎所有数据包都将包含 IN 的值 1（“Internet”）。您可能偶尔看到3 的CH（混乱）。

暂时就这些了 - 如果我想到其他任何内容，我会在稍后添加。

【讨论】：

如何检查操作码/Z 位是否设置正确？例如，操作码是 4 位，但只有 3 个有效值（0、1 和 2）。

OpCode 有 四个 分配（非过时）值，它们是 0、4、5 和 6。

【参考方案2】：

检查端口号怎么样？源端口和目标端口都应为 53。

【讨论】：

不，它将是端口 53，用于源或目标的 一个。一些较旧的解析器确实从端口 53 发送查询，但现在认为使用恒定源端口是非常糟糕的做法（参见 Kaminsky 错误）。