ルート53-SPFレコードをTXTレコードとして複製する必要がありますか？

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"

SPFRRタイプがより新しい標準であることは、実際には正しくありません（目的のSPF動作のコンテキストで）。SPF仕様の実験段階では、新しいレコードタイプが割り当てられていましたが、移行パスは不明であり、その後放棄されました。

SPF仕様の現在のバージョンでは、具体的に次のように述べられています。

SPFレコードは、DNS TXT（タイプ16）リソースレコード （RR）[RFC1035]としてのみ公開する必要があります。レコードの文字コンテンツは[US-ASCII]としてエンコードされます。代替DNS RRタイプの使用はSPFの実験段階でサポートされていましたが、廃止されました。

2003年にSPFが最初に開発されたとき
、新しい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の更新が開発された場合、SPF RRタイプを使用できます。SPF
が構造化データにTXT RRタイプを使用することは、
将来のプロトコル設計者にとって決して先例となるべきではありません。
新しいDNS RRタイプを使用する場合の設計上の考慮事項の詳細については、
[RFC5507]を参照してください。

補足として、例にはSender IDレコード（仕様は異なりますが、残念ながら "spf2.0"と呼ばれています）もありました。そのタイプのレコードのルールはまだ実験段階であり、SPFの実験バージョンと一致しています。仕様、更新は公開されていません。

はい、それらを複製します。実際にレコードタイプの現在の標準をサポートしているSPFチェッカーの比率がわからないのですが、ワイルドな推測をした場合、おそらく10％のチェッカーがSPFレコードを見ないだろうとだけ思っていますTXT。