我有一个包含3个TXT记录的DNS域：
@H_404_19@解决方法
$ORIGIN example.com. @ IN TXT "thing one veryveryveryveryveryverylong" @ IN TXT "thing two veryveryveryveryveryverylong" @ IN TXT "thing three veryveryveryveryveryverylong"
当我进行DNS查询(dig example.com .txt)时,回复适合UDP数据包,因为有效负载小于512字节(导致数据包小于576字节).
但是我知道如果回复足够长,它将被截断,DNS客户端将不得不使用TCP重复请求,TCP具有更长的长度限制.
如何在不生成DNS记录和进行查询的情况下计算是否超出了长度限制？
我假设公式是这样的：
N: the number of TXT records on that label. P: the number of bytes in all the TXT records. S: the total number of text segments (TXT records can have multiple text segments per record) UDP is required if N*a + P*b + S*c is more than 512
a,b和c的值是多少？
(或者我是朝错误的方向走？)
实际上,在实施TXT记录之前,您不应该尝试预先计算TXT记录的确切响应大小.游戏中有许多变量,其中一些是您无法控制的.大多数管理员根据他们从权威服务器观察到的现有TXT记录响应的大小进行概括,并将其称为一天.由于您的问题的焦点是如何避免泛化,这个答案将集中在为什么难以使用精确计算.
(这个答案不应被视为支持或反对试图保持在512字节以内的声明,它是对这种方法的评论.)
sDNSHeader + sQuestion + sAnswer + sAuthority + sAdditional
>查询本身显示在回复数据包的问题部分中,必须予以考虑.
>正如您所推测的那样,还必须考虑答案的数量和字节长度.
>如果权威服务器配置为列出权限部分中的名称服务器以及附加部分中的相应地址记录,则还必须考虑这些服务器.
>如果请求在附加部分中包含EDNS0伪部分,则兼容服务器将使用其自己的伪部分进行回复.如果EDNS0正在播放,查询可能请求大于512字节的消息大小,但它仍然是一个考虑因素,特别是因为通信路径中的网络硬件可能错误地拒绝> 512字节作为无效的DNS数据包并强制执行有效消息限制降到原来的限制.
> RFC 1035消息压缩也是一个因素.
你能编写一个程序或脚本来为你完成所有这些计算吗？当然.对于你想要解决的问题,它是否充分利用时间？可能不是.使用区域内的现有TXT记录作为粗略的大小调整指南,如果需要增加超过512字节,请确保熟悉利用TXT记录构建到相关标准中的任何“包含”功能. (SPF等)
