[ DNSとドメイン ]

DNS TXTレコード: 引用符、複数の文字列、レコード境界

電子メール認証を公開するときに、複数の文字列を含む 1 つのTXTレコードと複数の独立したTXTレコードの違いを保持します。

EmailAuth研究チームによる

【ポイント】

  • 1 つのTXTレコードには、順序付けされた複数の文字列を含めることができます。
  • SPFスペースを追加せずに文字列を結合し、個別のポリシーを結合しません。
  • バイトと所有者名を確認してから、実際のメール パスを確認します。
このページでは

DNSエディターは、複数のレコードを作成せずに、引用符で囲まれた複数のフラグメントを表示できます。逆に、受信者にとっては 2 つの独立したレコードが残る一方で、人にとっては 2 つの行が 1 つのポリシーのように見える場合もあります。認証レコードが正しいと宣言する前に、正確な値とレコード境界の両方を確認してください。

DNS表現を読み取る

参考文献: RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 7208 §3.3.

RFC 1035 、 TXTデータを 1 つ以上の文字列として定義しています。各文字列は 255 オクテットに制限されており、表示される文字数が 255 である必要はありません。長い値は、1 つのレコード内で複数の文字列を占める可能性があります。アプリケーションは、そのデータがどのように解釈されるかを定義します。のために SPF, RFC 7208文字列を連結することを明示的に要求しています。 記録 スペースを入れずに。

ゾーンファイルプレゼンテーション区切り文字列内の引用符。これらは、 DNS値内で自動的にリテラルの引用符になるわけではありません。プロバイダーのフォームでは、生のテキスト、引用符で囲まれたゾーンファイル構文、または文字列の構造化リストが必要になる場合があります。文書化された入力形式に従って、画面が見慣れたものになるまで引用符を追加または削除するのではなく、結果の回答を検査します。

スペースと独立したレコードを保存する

参考文献: RFC 7208 §4.5.

SPF値がメカニズムの直前で分割されている場合は、文字列の 1 つの内側に分離スペースを保持します。以下を含む 2 つの隣接する文字列 v=spf1 そして ip4:192.0.2.10 -all スペースのない無効なトークン シーケンスとして再構築されます。この不正な例では、再構築されたプレフィックスは次のようになります。 v=spf1ip4、これは有効なSPFバージョン トークンではありません。他のレコードがSPFポリシーとして選択されていない場合、 SPF結果は none になります。すべてのTXTコンシューマーが空白を同じように処理すると仮定するのではなく、正確なアプリケーション構文を保持します。

別々に参加しないでください TXTレコード 単にパーサーがそれらを 1 つのコレクションで返すからです。同じ所有者に無関係なTXTレコードが複数存在するのは正常です。その所有者でSPFポリシーとして選択された複数のレコードは次のとおりではありません。SPF SPFそれらの承認リストをマージするのではなく、永続的なエラーを返します。完全な回答とアプリケーションの選択ルールを診断に保存します。

境界テストを再現する

合成ゾーン フィクスチャ A には 1 つのレコードが含まれています。 example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.10" " -all "。バイトを追加せずに、その文字列を順番に再構築します。予想されるSPFテキストは次のとおりです v=spf1 ip4:192.0.2.10 -all。ドキュメントのアドレスは例示的なものであり、本番の送信者を認証するために使用してはなりません。

フィクスチャ B は A を 2 つのレコードに置き換えます。 example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.10 -all " そして example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.20 -all "。予期されるSPF選択は複数のポリシー レコードであり、永続的なエラーになります。フィクスチャ C は A を保持し、追加します example.com 。 300 IN TXT "サイト検証=合成";無関係な検証レコードは追加のSPFポリシーではありません。

隔離されたテストゾーンに各治具を個別にロードします。クエリ @AUTH example.comを掘ります。 TXT +norecurse、AUTH をラボ権限に置き換えます。返されたレコードごとに 1 つのリソース レコード オブジェクトとその順序付き文字列リストを保持します。忠実なハーネスでは、表示が長い出力をラップしている場合でも、A と B を区別する必要があります。これらは予想される結果であり、報告されたライブテストではありません。

公開された値を確認する

エディターの入力、それぞれの信頼できる回答、および再帰的な回答を比較します。所有者名を確認して、ゾーン サフィックスが誤って繰り返されていないか確認してください。チェックを自動化する場合は、レコード構造を保持するDNSライブラリを使用します。行指向のテキスト スクレイピングは、折り返しとレコード境界を混同する可能性があります。

生産変更の前に、以前の値と承認を保持します。公開後、関連するメール パスを無害なコンテンツでテストし、認証証拠を取得します。正しいTXT構文により、 DNS前提条件が確立されます。サービスがメッセージに署名したこと、または受信者がメッセージを受け入れたことを証明するものではありません。

証拠の範囲を明示的に保つ

ローカル文字列連結により、保存されたスペースがv=spf1 ip4:192.0.2.10 -allを生成することが確認されます。これを省略すると、選択されていないv=spf1ip4プレフィックスが生成されます。これはテキスト/選択の図であり、実行されたSPFエバリュエーターやライブDNSクエリではありません。

[ 取り除く ]

1 つのTXTレコードには、順序付けされた複数の文字列を含めることができます。 SPFスペースを追加せずに文字列を結合し、個別のポリシーを結合しません。バイトと所有者名を確認してから、実際のメール パスを確認します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

バイトとレコード境界を比較する

レコード内の文字列フラグメントと回答内の個別のレコードは、区別可能な状態を維持する必要があります。

次のステップ

  1. 順序付けされた文字列とレコードの境界を検査します。
  2. 重複ポリシーと分割文字列フィクスチャをテストします。
  3. 信頼できる回答と再帰的な回答を比較します。

CISO / SecOps

ポリシー公開パスを保護する

意味のある制御は、安心感を与えるスクリーンショットではなく、承認された検証可能なDNSデータです。

次のステップ

  1. 誰が認証DNSを変更できるかを確認します。
  2. 正確な前後の証拠が必要です。
  3. 構文チェックをメッセージ証明から分離します。

創業者 / 非技術系

DNS公開をサービス変更として扱う

プロバイダーのセットアップが完了しているように見えても、小さな形式ミスによりメールが中断される可能性があります。

次のステップ

  1. テスト済みの出版物チェックリストが必要です。
  2. 各送信サービスの所有者に名前を付けます。
  3. 回復の承認を利用可能な状態にしておきます。

[ よくある質問 ]

よくある質問

255 オクテットが最大TXTレコード サイズですか?

いいえ。これは文字列ごとの制限です。 DNSサイズの制約に従って、1 つのTXTレコードに複数の文字列を含めることができます。

RFC 1035 §3.3 RFC 1035 §3.3.14

SPF文字列の間にスペースを挿入しますか?

いいえ。実際の文字列には必要なスペースをすべて含めてください。

RFC 7208 §3.3

受信機は 2 つのSPFレコードを結合できますか?

いいえ。複数のSPFレコードを選択すると、永続的なエラーが発生します。

RFC 7208 §4.5

無関係なTXTレコードは共存できますか?

はい。アプリケーションは、独自の構文と所有者名に従ってレコードを選択します。

RFC 7208 §4.5

引用符文字をDNSフォームに貼り付ける必要がありますか?

プロバイダーの文書化された入力形式を使用して、実際のDNS値を検査します。

ラップされた表示は 2 つのレコードがあることを証明できますか?

いいえ。視覚的な改行ではなく、リソース レコードの境界を検査します。

レコードの名前が間違っているのはなぜですか?

一部の編集者は、相対名にゾーン接尾辞を追加します。対象の完全修飾所有者を照会します。

正しいTXTルックアップはDMARCに合格したことを証明しますか?

いいえ。認証と調整は代表的なメッセージで行われる必要があります。

RFC 9989 §5.3.5

[ 情報源 ]

情報源

  1. RFC 9989

    セクション §5.3.5

  2. RFC 7208

    セクション §3.3 · §4.5

  3. RFC 1035

    セクション §3.3 · §3.3.14

  4. ISC BIND ディグリファレンス

    セクション 構文、-x 逆引き参照、norecurse クエリ オプション

[ 用語集 ]

用語集

TXT文字列
最大 255 データ オクテットの長さで区切られた文字列。 TXT RR には、そのような文字列が 1 つ以上含まれています。

RFC 1035 §3.3 RFC 1035 §3.3.14

レコード境界
個別のリソース レコードと 1 つのレコード内の文字列との区別。 SPF選択では、個別のポリシーは結合されません。

RFC 7208 §3.3 RFC 7208 §4.5

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース