DNS 客户端是否应该担心 DNS 消息压缩（其中指针可能指向另一个指针而不是标签名称）？虽然这样做看起来很明确，但我所指的rfc中并没有谈论它。
来自 DNS rfc1035：
压缩方案允许消息中的域名表示为：
以零八位字节结尾的标签序列
一个指针
以指针结尾的标签序列
DNS 客户端可以期望服务器响应中出现这种行为吗？
答案1
是的，它可以。
我没有在任何相关的 DNS 标准中发现任何不允许这种情况的内容，因此如果您碰巧收到这种情况，您需要能够解码这种情况。消息压缩的定义RFC 1035 4.1.4说：
在此方案中，整个域名或域名末尾的标签列表被替换为指向先前出现的相同名称的指针。
这里没有任何内容表明这种情况必须是标签的字面列表。鉴于“裸指针”只是“以指针结尾的标签列表”的特殊情况，解码它不需要任何额外的复杂性。
指向指针的指针在野外很少见，因为没有真正的理由生成它们，而且它们会使编码复杂化。但就规范而言，它们似乎完全有效。
答案2
不（理论上，但实践中一切都可能发生）
令人惊讶的是，我认为答案在另一个 RFC 中：
第 3.3 节这样说：
目前，标签类型有两类：数据
标签和压缩标签。压缩标签是指向
RR 或 DNS 消息中其他位置的数据标签的指针，旨在缩短 NAME 的线路编码。
特别注意，它说压缩标签是指向数据标签的指针。它没有说压缩标签可以是指向其他压缩标签的指针，因此我觉得规范中没有指向指针的情况。
正如评论中所讨论的，规范并没有说这种情况是被禁止的，但他们也没有列出所有其他可能被禁止的事情。他们告诉我们什么是允许的，而其他一切都是不应该允许的。因此，我不同意 @TooTea 的回答，使用的论点是“规范中没有明确禁止，因此是允许的”以及由此得出的结论。
基于此，我得出的结论是，如果您想声明遵循 DNS 规范，则指针不应该指向另一个指针，但同时如果您必须处理任何未知的传入消息，您必须保护自己免受此类事件的影响，并且其他（如前向指针等），然后决定是接受还是拒绝。
波斯特尔定律可能会让你认为最好接受它，但我认为最好放弃这种信息而不是试图适应它，因为：
- 如上所述，这种情况不在规范中，所以“不应该发生”
- 我确实希望这种情况在野外很少见（但我没有任何证据）；因为下一点的原因
- 如果发生这种情况，则可能表明发送方的压缩算法不佳，因此无需尝试弥补该有缺陷的软件。
因为如果 X 指向 Y，Y 又指向 Z，为什么不直接让 X 指向 Z呢？拥有“中间”指针不提供任何附加功能，因此没有理由存在（除了错误和无效实现之外）。