时间戳

首页 > 解决方案 > 使用 Libpcap 解析 CNAME 的问题：一些 CNAME 似乎缺少 TLD

c++ - 使用 Libpcap 解析 CNAME 的问题：一些 CNAME 似乎缺少 TLD

问题描述

我正在使用 libpcap 编写 DNS 回复解析器，并发现相应的 DNS 数据包有效负载中似乎缺少一些 CNAME 的 TLD。一个示例显示在示例数据包的wireshark 剖析线鲨输出中，其中wireshark 显示实际CNAME 是

prd-push-access-net5-175542503.us-east-1.elb.amazonaws.com

但我只能找到

prd-push-access-net5-175542503.us-east-1.elb.amazonaws

（即没有“.com”）在有效载荷的相应部分。我想知道一个（以及wireshark如何）从这个有效载荷中解析出完整的CNAME（带有“.com”）？

（此外，这个 CNAME 似乎格式不正确，因为根据 RFC1035，有问题的 QNAME 部分应该“以根的空标签的零长度八位字节终止”，我猜这同样适用于 CNAME？）

标签： c++dnscnamelibpcap

解决方案

DNS 数据包使用名称压缩，参见https://www.rfc-editor.org/rfc/rfc1035 4.1.4 节

在许多地方（出现名称的地方），每个标签都可以用一个指针表示，该指针指向数据包中它已经出现的以前位置，而不是字符串。

在您的示例中，我们可以在数据包com的myfoscam.com前面清楚地看到。

因此对于内容（仅使用结尾，因为从图像中提取数据很繁琐，您应该将内容复制为文本）03656c6209616d617a6f6e617773c019c02e00，我们必须像这样分析它：

  • 03: 下面是一个长度为 3 的字符串
  • 656c62：这是字符串elb，广告中的长度为 3
  • 09: 下面是一个长度为 9 的字符串
  • 616d617a6f6e617773: 这是字符串amazonaws
  • c0：前两位为 1（因为它的值是 192，所以大于或等于 128+64），这意味着它是一个两字节指针的一部分。因此c019，这里是一个指向19数据包的十进制（十六进制）偏移量 25 处的指针。

因此，如果您从整个数据包开始，并切换到偏移量 25，您应该找到序列03636f6d是com（前缀长度为 3）。

或者可能是别的东西，因为你在 fact: 之后还有另一个指针c02e，所以这是消息中的偏移量 46。或者那部分完全是为了别的东西，它真的取决于前一个指针所指向的内容，它是否以空标签结束（如果它是否03636f6d00在偏移量 25 处）。请参阅 RFC 中的示例（和/或在您的问题中以文本形式提供所有数据包内容）

然后它以00空标签结束，这意味着根（隐藏.在任何名称的末尾）。

推荐阅读