Amazon Route 53 支持“SPF 记录”和“TXT 记录”。我读过的大多数文档都告诉我将我的 SPF 记录列为 TXT 记录。我知道 SPF 记录是一个较新的标准。因此,我复制我的 SPF 记录,以便将它们列为 SPF 记录和 TXT 记录,以确保向后兼容,同时遵循新标准,这样做是否正确?我不熟悉 DNS,所以不确定这是否会导致任何问题,或者我是否应该费心复制它们?
我的记录如下:
"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"
答案1
SPF
RR 类型是较新的标准(在所需 SPF 行为的背景下)实际上并不正确。SPF 规范的实验阶段已分配新的记录类型,但迁移路径不明确,因此已被放弃。
这SPF 规范的当前版本具体指出:
SPF 记录必须作为 DNS TXT(类型 16)资源记录发布 (RR)[RFC1035]仅有的。记录的字符内容编码为 [US-ASCII]。在 SPF 的实验阶段,支持使用替代 DNS RR 类型,但现已停止使用。
2003 年,当 SPF 首次开发时,
分配新 DNS RR 类型的要求比现在严格得多。此外,
DNS 服务器和配置系统中尚未广泛部署对轻松部署新 DNS RR 类型的支持
。因此,SPF 的开发人员发现
使用 TXT RR 类型进行 SPF 记录更简单、更实用。在审查 [RFC4408] 时,SPFbis 工作组得出结论,其双 RR 类型转换模型存在根本缺陷,因为它
不包含实施者必须遵守
和检查的通用 RR 类型。为解决
此问题,工作组考虑了许多替代方案,但最终得出结论,
在可预见的未来大规模迁移到 SPF RR 类型的
可能性很小,解决此
互操作性问题的最佳解决方案是从 SPF 版本 1 开始放弃对 SPF RR 类型的支持。
有关更多信息,请参阅 [RFC6686] 的附录 A。十年前 SPF 首次部署的情况非常独特。如果未来开发的 SPF 更新不重复
使用现有 SPF 记录,则可以使用 SPF RR 类型。SPF
对结构化数据使用 TXT RR 类型绝不应成为
未来协议设计者的先例。有关使用新 DNS RR 类型时的设计注意事项的进一步讨论,
请参阅
[RFC5507]。
附注:您的示例中还有一个发件人 ID 记录(不幸的是,尽管它是不同的规范,但被称为“spf2.0”),该类型记录的规则仍处于实验阶段,并且 [与 SPF 规范的实验版本相匹配](https://tools.ietf.org/html/rfc4406#section-4.3),尚未发布任何更新。
答案2
是的,复制它们;我不知道有多少比例的 SPF 检查器实际上支持当前的记录类型标准,但如果我大胆猜测的话,我敢打赌,可能有 10% 的检查器不会查看记录SPF
,只会TXT
。