sockets - 识别 DNS​​ 数据包

Question

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

Answer 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                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

正如您在上面看到的， header 长 12 个字节 - 一个 2 个字节的 ID、2 个字节的标志和 4 x 2 个字节的计数。
在任何 DNS 数据包中， QDCOUNT字段将正好是 1 ( 0x0001 )。从技术上讲，协议(protocol)允许使用其他值，但实际上它们从未使用过。
在查询 ( QR == 0) 中， ANCOUNT和 NSCOUNT值将完全为零( 0x0000 )，而 ARCOUNT通常为 0、1 或 2，具体取决于 EDNS0 (RFC 2671)和 TSIG (RFC 2845)正在使用。 RCODE在查询中也将为零。
除非您观察对话的双方并且可以将每个响应与触发它的查询相关联，否则响应有点难以识别。
显然 QR位将被设置，如上 QDCOUNT应该还是一个。然而，其余的计数器将有许多不同的排列。但是，任何计数器都不太可能大于 255，因此您应该能够依赖字节 4、6、8 和 10 都为零。
在标题之后，您将开始查找资源记录，第一个是实际提出的问题(第 4.1.2 节)。不幸的是，协议(protocol)的设计者认为在两个固定字段( QNAME 和 QTYPE)前面包含一个可变长度标签字段( QCLASS)是合适的。
[更复杂的是，可以使用指向数据包中其他位置的反向指针来压缩标签。幸运的是，您几乎不会在问题部分看到压缩标签，因为根据定义，您不能从那里倒退。从技术上讲，不正当的实现者可以将压缩指针发送回 header ，但这不应该发生]。
因此，开始读取每个长度字节，然后跳过那么多字节，直到达到空字节，然后接下来的两个 16 位字将是 QTYPE和 QCLASS .很少 legal values对于 QCLASS ，并且几乎所有数据包都将包含值 1对于 IN (“互联网”)。您可能偶尔会看到 3对于 CH (困惑)。
暂时就这些了 - 如果我想到其他任何内容，我会在稍后添加。