Skip to main content

3. SPF Records (SPF 记录)

3. SPF Records (SPF 记录)​

SPF 记录是一个 DNS 记录, 声明哪些主机被授权（以及哪些未被授权）在 "HELO" 和 "MAIL FROM" 标识中使用域名。宽泛地说, 该记录将主机分为允许和不允许的集合（尽管某些主机可能不属于任何一类）。

SPF 记录表示为在单个 DNS TXT 资源记录的 RDATA 中找到的单个文本字符串; 不允许同一所有者名称有多个 SPF 记录。记录格式和选择记录的过程在下面的第 4 节中描述。一个示例记录如下:

v=spf1 +mx a:colo.example.com/28 -all

此记录的版本为 "spf1", 包含三个指令: "+mx", "a:colo.example.com/28"（隐含 "+"）, 和 "-all"。

每个 SPF 记录放置在 DNS 树中它所属的所有者名称处, 而不是在所有者名称下的子域中。这类似于 SRV 记录 [RFC2782] 的做法。

本节中的示例可能通过域区域文件中的以下行发布:

example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"

由于 TXT 记录有多种用途, 请注意在那里为其他目的发布的其他 TXT 记录。它们可能会导致大小限制问题（参见第 3.4 节）, 必须注意确保仅将 SPF 记录用于 SPF 处理。

发布 SPF 记录的 ADMD 应该将评估记录所需的 DNS 信息量保持在最低限度。第 4.6.4 节和第 10.1.1 节提供了一些关于 "include" 机制和链式 "redirect" 修饰符的建议。

3.1 DNS Resource Records (DNS 资源记录)​

SPF 记录必须仅作为 DNS TXT（类型 16）资源记录（RR）[RFC1035] 发布。记录的字符内容编码为 [US-ASCII]。SPF 实验阶段支持使用替代 DNS RR 类型, 但现已停止。

2003 年, 当 SPF 首次开发时, 分配新 DNS RR 类型的要求比现在严格得多。此外, 对于轻松部署新 DNS RR 类型的支持在 DNS 服务器和配置系统中并未广泛部署。因此, 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] 中找到。

3.2 Multiple DNS Records (多个 DNS 记录)​

域名绝对不能有多个记录会导致授权检查选择多个记录。有关选择规则, 请参见第 4.5 节。

3.3 Multiple Strings in a Single DNS Record (单个 DNS 记录中的多个字符串)​

如 [RFC1035] 第 3.3 节和第 3.3.14 节中所定义, 单个文本 DNS 记录可以由多个字符串组成。如果发布的记录包含多个字符字符串, 则必须将该记录视为这些字符串在不添加空格的情况下连接在一起。例如:

IN TXT "v=spf1 .... first" "second string..."

等价于:

IN TXT "v=spf1 .... firstsecond string..."

包含多个字符串的 TXT 记录对于构建超过单个 TXT 记录中字符字符串的 255 八位字节最大长度的记录很有用。

3.4 Record Size (记录大小)​

给定域名发布的 SPF 记录应该保持足够小, 以便对其的查询结果适合 512 八位字节内。否则, 有可能超过 DNS 协议限制。此 UDP 限制在 [RFC1035] 第 2.3.4 节中定义, 尽管它被 [RFC2671] 提高了。保持在 512 八位字节以下应该可以防止较旧的 DNS 实现失败转移到 TCP, 并且在没有 EDNS0 [RFC6891] 支持的情况下可以使用 UDP。由于应答大小取决于本文档范围之外的许多事情, 因此只能给出以下指导: 如果 DNS 消息的大小, DNS 名称和给定类型的所有记录的文本的组合长度小于 450 八位字节, 那么 DNS 应答应该适合 UDP 数据包。由于防火墙和其他干扰 TCP 上的 DNS 操作或使用 EDNS0 的问题, 太长而无法装入单个 UDP 数据包的记录可能会被 SPF 验证器静默忽略。

请注意, 在计算 TXT 格式查询的回复大小时, 必须考虑在域名处发布的任何其他 TXT 记录。类似地, 必须评估与 SPF 相关的所有查询的回复大小, 以适合单个 512 八位字节的 UDP 数据包（即, DNS 消息大小限制为 450 八位字节）。

3.5 Wildcard Records (通配符记录)​

不鼓励使用通配符记录进行发布, 如果使用它们, 必须小心。如果一个区域包含通配符 MX 记录, 它可能希望发布通配符声明, 但需要遵守相同的要求和问题。特别是, 对于具有任何 RR 记录的任何主机以及其子域, 必须重复该声明。考虑 [RFC1034] 第 4.3.3 节中的示例。基于此, 我们可以执行以下操作:

EXAMPLE.COM. MX 10 A.EXAMPLE.COM
EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

A.EXAMPLE.COM. A 203.0.113.1
A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

对于区域内的每个名称, SPF 记录必须列出两次: 一次用于该名称, 一次使用通配符来覆盖该名称下的树, 以覆盖传出邮件中使用的所有域。

Last updated on