Sockets 识别DNS数据包

当查看数据包字节码时，您将如何识别dns数据包。

---

IP报头的协议字段会告诉我们后面有一个UDP帧，但在UDP帧内不存在协议字段来指定下一个是什么，从我所看到的情况来看，帧内没有任何内容可以唯一地将其标识为dns数据包。

检查端口号如何？源端口和目标端口都应为53。

除了它位于端口53上之外，您还可以注意一些事情，它们可能会提示您正在查看DNS流量

我将在此处引用批次§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

字段将正好是一个（

0x0001

）。从技术上讲，协议允许使用其他值，但实际上从未使用过

在查询（

QR==0

）中，

ANCOUNT

和

NSCOUNT

值将精确为零（

0x0000

），而

ARCOUNT

通常为0、1或2，具体取决于使用的是

EDNS0

和

TSIG

RCODE

在查询中也将为零

回答有点难以识别，除非您观察对话的双方，并且可以将每个回答与触发它的查询关联起来

显然，将设置

QR

位，如上所述，

QDCOUNT

仍应为1。然而，剩余的计数器将有许多不同的排列。但是，任何计数器都不太可能大于255，因此您应该能够依赖字节4、6、8和10都为零

在标题之后，您将开始查找资源记录，第一个是实际提出的问题（§4.1.2）。不幸的是，协议的设计者认为在两个固定字段（

QTYPE

和

QCLASS

）前面包含一个可变长度标签字段（

QNAME

）是合适的

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

因此，开始读取每个长度字节，然后跳过许多字节，直到达到一个空字节，然后接下来的两个16位字将是

QTYPE

和

QCLASS

。对于

QCLASS

，几乎所有的数据包都将包含

中
的值
1
。您可能偶尔会看到
CH
（混沌）的
3

现在就这样-如果我想其他什么，我会在以后添加它。
不，对于源或目标之一，它将是端口53。一些较旧的解析程序确实从端口53发送查询，但现在使用恒定源端口被认为是非常糟糕的做法（参见Kaminsky bug）。检查操作码/Z位设置是否正确如何？例如，操作码为4位，但只有3个有效值（0、1和2）。操作码有四个指定（非过时）值，分别为0、4、5和6。