メインコンテンツまでスキップ

3. SPF Records (SPFレコード)

3. SPF Records (SPFレコード)​

SPFレコードは、「HELO」および「MAIL FROM」アイデンティティでドメイン名を使用することが許可されている(および許可されていない)ホストを宣言するDNSレコードです。大まかに言えば、レコードはホストを許可されたセットと許可されていないセットに分割します(ただし、一部のホストはどちらのカテゴリにも属さない場合があります)。

SPFレコードは、単一のDNS TXTリソースレコードのRDATA内で見つかる単一のテキスト文字列として表されます。同じ所有者名を持つ複数のSPFレコードは許可されていません。レコード形式とレコード選択のプロセスは、以下のセクション4で説明されています。レコードの例は次のとおりです:

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

このレコードはバージョン「spf1」で、3つのディレクティブを含んでいます: 「+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サーバーおよび構成システムでの新しいDNS RRタイプの簡単な展開のサポートは広く展開されていませんでした。したがって、SPFの開発者は、SPFレコードを保存するためにTXT RRタイプを使用する方が簡単で実用的であることを発見しました。

[RFC4408]のレビューにおいて、SPFbisワーキンググループは、そのデュアルRRタイプ移行モデルは、実装者が提供および検証する必要のある普遍的なRRタイプを含んでいなかったため、根本的に欠陥があると結論付けました。この問題を解決するために多くの代替案が検討されましたが、最終的にワーキンググループは、予測可能な将来にSPF RRタイプへの移行の可能性は非常に低く、この相互運用性の問題に対する最良の解決策は、SPFバージョン1からSPF RRタイプのサポートを削除することであると結論付けました。詳細については、[RFC6686]の付録Aを参照してください。

10年前の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レコードは2回リストする必要があります: その名前に対して1回、その名前の下のツリーをカバーするためにワイルドカードで1回、送信メールで使用されるすべてのドメインをカバーします。

に最終更新