SPF 与其他 TXT 记录的大小

SPF 与其他 TXT 记录的大小

SPF 规范说:

针对给定域名发布的 SPF 记录应保持足够小,以便查询结果可以容纳在 512 个八位字节内。否则,可能会超出 DNS 协议限制。

请注意,在计算 TXT 格式查询的回复大小时,必须考虑在域名上发布的任何其他 TXT 记录。

它还指出,较新的 DNS 规范允许更大的 UDP 响应(限制的原因,因为 SPF 规范意味着您不应该依赖 DNS over TCP 工作),但这似乎并没有真正覆盖“应该”。

问题在于,许多组织出于验证目的需要同一域上的 TXT 记录(例如,,,,facebook-domain-verification等) google-site-verification,并且可以快速将总 TXT RRset 的大小增加到超过 512 字节。atlassian-domain-verificationadobe-sign-verification

看起来大多数大型组织都遵守这一点,但也有一些组织超出了这一点:

% dig +noall +stats netflix.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 593

% dig +noall +stats linkedin.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 632

% dig +noall +stats twitter.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 642

% dig +noall +stats microsoft.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 1459

(您可以通过运行类似命令来查看可能发生的截断情况dig +notcp +noedns +ignore microsoft.com TXT。)

六个月来,我一直处于困境之中,现在我需要为新供应商添加另一条验证记录,这将使我的记录大小远远超过 512 字节。我已尽我所能整合我的 SPF 记录,并确保无法删除现有的验证记录。

我该怎么办?我不能没有验证记录,但我也不想忽略 SPF 规范。话虽如此,微软似乎忽略了这一点,我不认为他们的邮件被拒绝了。

答案1

重新阅读 SPF 规范后,对 TXT RRset 大小的担忧是,如果客户端两个都不支持 EDNS客户端不支持 DNS over TCP。DNS over TCP 一直是 DNS 的必需部分,警告似乎与 DNS 故障有关。(公平地说,有很多地方 DNS over TCP 出现故障,尤其是过去。)

但我知道我的 DNS 服务器可以通过 TCP 访问,而且我更关心的是确保其他人的 DNS 支持(相对)新的 DNS 规范,而不是其他人的 DNS 主动中断。

所以答案似乎是“忽略[该]项目的正当理由,[和]全部影响[已被]理解和仔细权衡”

相关内容