ルート53-SPFレコードをTXTレコードとして複製する必要がありますか？
Amazon Route 53は、「SPFレコード」と「TXTレコード」の両方をサポートしています。私が読んだほとんどのドキュメントでは、SPFレコードをTXT Recordとしてリストするように指示されています。SPFレコードが新しい標準であることを理解しています。したがって、SPFレコードを複製して、 SPFレコードおよびa TXT Record for a後方互換性を確保するための新しい標準に従っていますが、私はDNSに慣れていないので、これが問題を引き起こすかどうか、またはそれらを複製する手間？
私の記録は次のとおりです。
"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"
SPF RRタイプが新しい標準であることは実際には正しくありません（目的のSPF動作のコンテキストで）。 SPF仕様の実験段階 には新しいレコードタイプが割り当てられていましたが、移行パスが不明確で、それ以降、それは放棄されました。
SPF仕様の現在のバージョン は具体的に次のように述べています。
SPFレコードDNSとして公開する必要がありますTXT（type 16）Resource Record（RR）[RFC1035]only。レコードの文字コンテンツは[US-ASCII]としてエンコードされます。SPFの実験段階では、代替DNS RRタイプの使用がサポートされていましたが、廃止されました。
SPFが最初に開発された2003年に、
新しいDNS RRタイプの割り当ては、現在よりもはるかに厳格でした。さらに、新しいDNSの簡単な展開のサポート
RRタイプはDNSサーバーとプロビジョニングに広く導入されていませんでした
システム。その結果、SPFの開発者はそれをより簡単に、より
SPFレコードにTXT RRタイプを使用するのが実用的です。[RFC4408]のレビューで、SPFbisワーキンググループは、そのデュアルRRタイプの移行モデルには根本的な欠陥があると結論付けました。
実装者が提供する必要のある一般的なRRタイプが含まれていない
チェックする必要があります。多くの選択肢が解決すると考えられました
この問題ですが、最終的にワーキンググループは、
近い将来、SPF RRタイプへの大幅な移行
はほとんどありませんでした。これを解決するための最良のソリューション
相互運用性の問題は、SPF RRタイプのサポートを
SPFバージョン1。詳細については、[RFC6686]の付録Aを参照してください。10年前のSPFの初期導入を取り巻く状況は独特です。 SPFの将来のアップデートが開発されたが、
既存のSPFレコードを再利用します。SPFRRタイプを使用できます。 SPFの使用
TXTの構造化データのRRタイプは、
将来のプロトコル設計者のための先例。のさらなる議論
新しいDNS RRタイプを使用する際の設計上の考慮事項は、
[RFC5507]。
補足として、例にはSender IDレコード（仕様が異なるにもかかわらず残念ながら "spf2.0"と呼ばれています）もありました。そのタイプのレコードのルールはまだ実験的であり、- SPF仕様の試験版と一致 、更新は公開されていません。
はい、それらを複製します。実際にレコードタイプの現在の標準をサポートしているSPFチェッカーの比率がわからないのですが、10％のチェッカーがSPFレコードを調べず、TXTだけを調べようと思います。 。