domain-name-system – 混合SPF记录

概述我的DNS中有通常的Google Apps SPF记录： v=spf1 include:_spf.google.com ~all 现在,既然我们正在使用ZenDesk,我还应该补充： v=spf1 include:support.zendesk.com ~all 他们应该合并成这样的： v=spf1 include:_spf.google.com include:support.zendesk.c 我的DNS中有通常的Google Apps SPF记录：

v=spf1 include:_spf.Google.com ~all

现在,既然我们正在使用ZenDesk,我还应该补充：

v=spf1 include:support.Zendesk.com ~all

他们应该合并成这样的：

v=spf1 include:_spf.Google.com include:support.Zendesk.com ~all

解决方法 是的,这是正确的,除非_spf.Google.com包含重定向(它没有).在这种情况下,包括：_spf.Google.com应该移动到列表的末尾,以避免在包含重定向后替换所有条目

此外,请注意RFC(IETF RFC4408)指定应允许最多10个MX或PTR查找,之后,应终止单个记录的验证.这是为了确保SPF解析器不会陷入无休止的查找场景(潜在的DoS).

这在现实生活中如何应用？
假设两者都使用“mx”机制,并且每个机制都有6个不同的MX记录.现在,当第一个包含(_spf.Google.com)已被处理时,您只剩下4个查找,可以这么说.如果正在验证的MTA是第二个包含的最后2个不同MX记录(support.Zendesk.com),则即使您已正确包含所有记录,验证也可能实际失败.

对于上述情况并非如此,但值得考虑,因为在设计SPF结构时并非所有公司都会考虑这一点.只是尝试查找,例如,TXT for ebay.com并尝试计算可能导致的查找次数;-)

总结

以上是内存溢出为你收集整理的domain-name-system – 混合SPF记录全部内容，希望文章能够帮你解决domain-name-system – 混合SPF记录所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。