用Libpcap解析CNAME的一个问题:一些CNAME似乎缺少TLD

Question

我正在用libpcap编写DNS应答解析器，并发现一些CNAMEs的TLD似乎在相应的DNS数据包有效负载中丢失。一个例子出现在一个包的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也是如此吗？)

Answer 1

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是在十进制偏移量25 (十六进制的19)处指向数据包的指针。

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

或者其他的东西，因为实际上后面有另一个指针：c02e，所以这是用于偏移消息46的。或者，这个部分完全是针对其他东西的，它实际上取决于以前的指针指向什么，它是否以空标签结束(如果它在偏移量25处是03636f6d00 )。参见RFC中的示例(和/或在您的问题中以文本形式提供所有数据包内容)

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