[ DNSとドメイン ]

スプリットホライズンDNS : 内部認証レコードとパブリック認証レコードを比較します。

内部認証の検索は成功したが外部メールが失敗した場合に、プライベートDNSビュー、パブリック権限、およびキャッシュを区別します。

EmailAuth研究チームによる · 8 分で読めます

【ポイント】

  • 各DNS観察に、そのリゾルバーとネットワーク上の有利なポイントをラベル付けします。
  • 意図的なビューの違いをキャッシュや一貫性のないパブリケーションから分離します。
  • 必要な公開認証データのみを公開し、受信したメッセージをテストします。
このページでは

[ 取り除く ]

ローカルでの成功は一般の受け入れテストではありません。関連するビュー全体で正確な所有者を比較し、外部送信パスを個別に証明します。

【役割別】

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

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

IT / メール管理者

正確なメッセージ ID を比較する

異なる検索は、それぞれのDNSビューに対して両方とも正しい可能性があります。

次のステップ

  1. 実際のエンベロープ ドメインとDKIMセレクターを記録します。
  2. プライベート、パブリックの再帰的、およびパブリックで権威のある回答を比較します。
  3. タイムスタンプ、TTL、エラーを保持します。

CISO / SecOps

プライベートゾーンをプライベートに保つ

内部名前空間を公開せずにパブリック認証を修正します。

次のステップ

  1. 必要な公的記録のみを承認します。
  2. エイリアスと委任の依存関係を確認します。
  3. 内部ゾーンのエクスポートを公的修復の対象外にします。

創業者 / 非技術系

失敗した顧客パスを解決する

Office テストでは、外部から見える配信エラーを見逃す可能性があります。

次のステップ

  1. ビジネス ワークフローと外部の受け入れ受信者に名前を付けます。
  2. 一時的なキャッシュ効果を永続的なビューの違いから分離します。
  3. 新しいメッセージのテスト後に責任あるサインオフを要求します。

[ よくある質問 ]

よくある質問

スプリットホライズンDNSとは何ですか?

これは、名前空間のDNS応答がクエリのソースまたはその他のビュー選択属性に応じて異なる構成です。内部クライアントと外部クライアントには異なるゾーン データが表示される場合があります。

RFC9499

受信者がDKIM検証できないのにオフィス検索が成功するのはなぜですか?

オフィスは、公的権限が及ばないキーを含むプライベートゾーンを照会する場合があります。これが原因であると結論付ける前に、両方のビューでメッセージからの正確なセレクター所有者を比較してください。

RFC6376

待っていると常に社内の回答と公開の回答が一致しますか?

いいえ。意図的なビューの相違は、キャッシュされた回答のように期限切れになりません。不一致をキャッシュの問題として扱う前に、どの権限とビューが各結果を提供したかを確認してください。

RFC9499

ラップトップをフラッシュして受信者のキャッシュをクリアできますか?

いいえ。ローカル フラッシュでは、信頼できるデータや、キャッシュされた別のリゾルバーの肯定応答または否定応答は変更されません。関連するリゾルバーとタイミングの証拠をキャプチャします。

RFC2308

SERVFAIL 、 TXTレコードが欠落していることと同じですか?

いいえ。サーバー障害はエラーの結果であり、レコードが存在しないという正式な宣言ではありません。応答ステータスを保存し、解決パスを調査します。

RFC1035

プライベート ゾーン全体をパブリックDNSにコピーする必要がありますか?

いいえ。提案された運用計画では、外部ルートに必要な承認済みの認証レコードのみが公開されます。プライベート サービスとアドレスは、意図的に非公開のままにすることができます。

RFC9499

どのSPF所有者を比較する必要がありますか?

メッセージに対して評価されたSMTP ID (通常はエンベロープ送信者ドメイン) を使用します。表示されている From ドメインで便利なTXTレコードを比較すると、間違った所有者を調査できる可能性があります。

RFC7208

同一のDNS応答はDMARC成功を保証しますか?

いいえ。受信したメッセージには、該当するポリシー設定で表示される From と一致する認証パスを渡す必要があります。

RFC9989

[ 情報源 ]

情報源

  1. RFC9499

    セクション §6. DNSサーバーとクライアント · §7.ゾーン

  2. Microsoft: スプリットブレインDNS導入

    セクション スプリット ブレインDNS展開 · ゾーン スコープとDNSクエリ解決ポリシー

  3. RFC1034

    セクション §4.2.1 技術的考慮事項 · §4.2.2 管理上の考慮事項 · §4.3.2 アルゴリズム

  4. RFC2308

    セクション §2.否定的な反応 · §5。否定的な回答のキャッシュ

  5. RFC1035

    セクション §3.3.11 NS RDATA フォーマット · §3.3.13 SOA RDATA フォーマット · §4.1 メッセージフォーマット

  6. RFC7208

    セクション §4. SPF評価 · §4.5 レコードの選択 · §4.6.4 DNSルックアップ制限

  7. RFC9989

    セクション 識別子の調整 · DMARCポリシーの検出

  8. RFC6376

    セクション §3.5 DKIM-Signatureヘッダー フィールド · §3.6 鍵の管理と表現 · §6。検証者のアクション

[ 用語集 ]

用語集

DNSビュー
クエリ属性またはサーバー ポリシーに従って提示される、選択されたDNS回答セット。

RFC9499

見晴らしの良い場所
DNS観察が行われるネットワークおよびリゾルバー コンテキスト。

RFC9499

ネガティブキャッシュ
名前または要求されたデータが存在しないことを示す保存された応答が、ネガティブ キャッシュ ルールに基づいて保持されました。

RFC2308

公的機関
権威DNS 、パブリック委任チェーンを通じて所有者名に到達しました。

RFC1034

企業の来歴

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

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

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

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

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

ナレッジベース