问DNS查询之前有多少TXT数据不适合UDP数据包？

EN

在实践中，您不应该在实现TXT记录之前预先计算它们的确切响应大小。有许多变量在发挥作用，其中有些你无法控制。大多数管理员根据他们从权威服务器观察到的现有TXT记录响应的大小进行概括，并将其称为一天。既然你的问题的重点是如何避免泛化，这个答案将集中在为什么它是很难使用精确的计算。

(不应将此答案视为支持或反对试图保持在512字节以内的声明，这是对用于此操作的方法的评论。)

sDNSHeader + sQuestion + sAnswer + sAuthority + sAdditional

• 查询本身显示在答复包的问题部分，必须加以考虑。
• 正如您所推测的，答案的数量及其字节长度也必须考虑在内。
• 如果权威服务器被配置为在授权部分列出名称服务器，在附加部分中列出相应的地址记录，那么这些地址记录也必须被考虑在内。
• 如果请求在附加部分中包含一个EDNS0伪节，则兼容的服务器将使用自己的伪节进行答复。如果使用EDNS0，查询可能请求大于512个字节的消息大小，但这仍然是一个考虑因素，特别是因为通信路径中的网络硬件可能错误地拒绝DNS数据包>512个字节为无效，并强制将有效消息限制降回原始约束。
• RFC 1035消息压缩也是一个因素。

你能写一个程序或脚本来完成所有这些计算吗？好的。对你想要解决的问题来说，这是一个很好的利用时间吗？可能不会。使用区域内现有的TXT记录作为粗略的大小调整指南，如果增长超过512字节，请确保您熟悉在相关标准中内置的任何"include“功能，利用TXT记录。(SPF等)

历史上，DNS的有效负载为512辛特，其中10辛特是一个固定的头。您必须为将包含在答复中的问题部分的副本腾出空间。这大概是问题的名字加上四个八位数。每个TXT将使用一个指向问题名的压缩指针作为其所有者名称。那是两个八位数。然后是10位字节的固定开销(ttl、class、type和rdlen)。与多个离散的TXT RR相比，您将更多的文本放入一个真正长的TXT RR中。通常，您应该尝试在一个区域中输入一组不同的TXT，然后使用"dig“来获取每个区域，并查看"dig”表示的有效载荷是多长时间。

历史上的512个数字是为IPv4选择的，但对于IPv6则不是轻松的。在IPv4中，有效负载加上最坏的UDP和IP报头将产生一个568个八进制IP数据报，这是最低允许的最小重新组装缓冲区大小--如果IPv4终端站不能至少重新组装那么多，那么它是“不符合”的，因此，没有人允许假设您可以重新组装更多。

在现代DNS中，缓冲区大小将使用OPT ("EDNS0")协商，通常为4096。这反映了终端站实际上可以重新组装的大于-568个八位数的大小。显然，EDNS0缓冲区的大小大于您的以太网MTU (或者您发现的路径MTU )将导致IP碎片，这通常会导致损失，因为防火墙不允许它。当EDNS0 @4K失败时，它通常会在1460重新尝试(为IP和UDP报头留出空间，加上有效负载，并且仍然适合于以太网数据包)，然后在512下重试，然后在没有EDNS0的情况下重试(也就是512)。如果您依赖于EDNS，您通常会发送TC=1 (“截断发生了”)，在这种情况下，请求者可能会重新尝试使用TCP，或者完全失败。

这意味着，如果您依赖于512以上，那么您将大量使用TCP。因为您的问题是关于UDP的，这可能意味着您应该适应512。

如果我读对了RFC1035，你有：

Header: 12 bytes
Question: querylen +1(null term)+4
Answer: N*(namelen+1+10+(S*(1+txtlen)))

因此，对于您的示例(其中每个TXT记录只有一个文本段S)：

query = example.com
querylen = 11
name: I'm not sure if that would be blank or example.com in your example
but I think it would be example.com, so

namelen = 11
txtlen1 = 38
txtlen2 = 38
txtlen3 = 40

所以，我们有12+11+5=28 +答案

P1 = Answer1 = 11+11+1+38 = 61
P2 = Answer1 = 11+11+1+38 = 61
P3 = Answer1 = 11+11+1+40 = 63

28+61+61+63=213