索引的DNS名称压缩>；16383

DNS名称压缩（第4.1.4节）16位指针包含一个14位偏移字段，该字段“指定从消息开头的偏移量”代替标签。这允许指针引用数据包前16383字节内的标签，但EDN允许数据包大小高达65535字节，是否有方法指向索引>16383的名称？

答案：

要回答您的问题，首先，到目前为止，无法指定大于214-1（16383）的偏移量。规范可能会在未来发生变化：一些RFC可能会用一些勘误表进行更新，它们可能会被最近的RFC淘汰，即使不改变RFC，也可以在IANA标签类型注册表中添加新的标签类型

其次，即使RFCs中没有提到绝对最大有效负载大小，最新的标准跟踪关于DNS的RFC（RFC-6891）说，折衷方案可能是使用4096的EDNS最大有效负载大小。因为214比4096大得多，所以这不是问题

解释：

获取新标签类型（例如三个八位组序列）的唯一方法是将其注册到IANA维护的DNS标签类型注册表中，如处理标签类型的最新标准跟踪RFC中所述：。这是因为此RFC反对RFC-2671引入的扩展标签类型注册表（RFC-6891说明：因此没有扩展标签类型注册表，所有标签类型都注册在DNS标签类型注册表中）。因此，只有一个注册表：DNS标签类型注册表，它同时注册标准标签类型和扩展标签类型

因此，要检查是否存在新的标签类型，我们只需查看IANA注册中心，该注册中心正式维护在IANA web服务器上：

此注册表中的DNS标签类型部分有一个表，其中仅包含现有的6种标签类型格式。这些是：

• 正常标签：低6位是标签的长度
• 压缩标签：下一个八位字节的下6位和8位组成指向压缩目标的指针
• 扩展标签类型：此类型的低6位表示正在使用的标签类型
• 二进制标签
• 预留作日后扩展之用
• 未分配

有些是不推荐的，有些是建议的，但根据IANA的同一文件，唯一属于标准的标签类型是普通标签和压缩标签

---

正如您所见，没有任何其他标签类型（扩展或非扩展）能够比“压缩标签”类型（指定偏移量为14位的类型）更灵活地压缩域名。

“指针采用两个八位序列的形式：“2个八位，即16位，减去开始时固定在值1的2，因此为14位，或2^14个值，即16384。你是怎么到4095的？那么你可能会说，这仍然是65535短，但想法是压缩名称，即标签“在一个给定记录的开始”，而不是真正的记录内的数据啊，我的错误，最大指针值将是

0x3fff

或16383，我在想

0x0fff

，我将编辑它注意到，在您设想的情况下，它意味着16384或更高位置的“某物”需要在它之前的另一个位置引用相同的名称（但仍然在16384之后），并且哪个名称永远不会出现在16384位置之前，这当然是可能的，但我认为是不可能的。请再次记住，这仅用于名称（标签）压缩，而不是一般数据压缩，为了进一步支持我之前的评论，请参阅RFC3597，特别是这句话：为避免此类损坏，服务器不得压缩嵌入特定于类或未知类型的RDATA中的域名。[RFC1123]中说明了该要求，但未定义术语“众所周知”；特此规定，只有[RFC1035]中定义的RR类型被视为“已知”。RFC1035只定义了：CNAME，MX，NS，PTR，SOA，TXT，A。所以除了TXT，我不相信你能得到你想要的情况。名称压缩是可选的（程序可以自由避免在其生成的消息中使用指针，尽管这会减少数据报容量，并可能导致截断。但是，所有程序都需要理解包含指针的到达消息。），这不是强制性的。因此，如果无法用有效指针表示，请不要压缩。简单：-）当然，您描述的数据包似乎已经超出了图表长度……RFC6891明确警告：由于客户端和中间网关中缺乏支持，扩展标签类型极难部署，如[RFC3363]中所述，它将[RFC2673]移至实验状态；和[RFC3364]，其中描述了优点和缺点。因此，考虑扩展标签的提案应权衡此部署成本与以其他方式实现功能的可能性。绝对是的，而且，许多实现（如网箱）都不符合RFCs 1034/1035的要求，因此，更改或扩展规范中如此关键的部分是一个非常糟糕的想法。