[ DNSとドメイン ]
スプリットホライズンDNS : 内部認証レコードとパブリック認証レコードを比較します。
内部認証の検索は成功したが外部メールが失敗した場合に、プライベートDNSビュー、パブリック権限、およびキャッシュを区別します。
EmailAuth研究チームによる · 8 分で読めます
【ポイント】
- 各DNS観察に、そのリゾルバーとネットワーク上の有利なポイントをラベル付けします。
- 意図的なビューの違いをキャッシュや一貫性のないパブリケーションから分離します。
- 必要な公開認証データのみを公開し、受信したメッセージをテストします。
[ 取り除く ]
ローカルでの成功は一般の受け入れテストではありません。関連するビュー全体で正確な所有者を比較し、外部送信パスを個別に証明します。
【役割別】
これがあなたにとって何を意味するか
実際の次のステップに向けて、自分の役割を選択してください。
IT / メール管理者
正確なメッセージ ID を比較する
異なる検索は、それぞれのDNSビューに対して両方とも正しい可能性があります。
次のステップ
- 実際のエンベロープ ドメインとDKIMセレクターを記録します。
- プライベート、パブリックの再帰的、およびパブリックで権威のある回答を比較します。
- タイムスタンプ、TTL、エラーを保持します。
CISO / SecOps
プライベートゾーンをプライベートに保つ
内部名前空間を公開せずにパブリック認証を修正します。
次のステップ
- 必要な公的記録のみを承認します。
- エイリアスと委任の依存関係を確認します。
- 内部ゾーンのエクスポートを公的修復の対象外にします。
創業者 / 非技術系
失敗した顧客パスを解決する
Office テストでは、外部から見える配信エラーを見逃す可能性があります。
次のステップ
- ビジネス ワークフローと外部の受け入れ受信者に名前を付けます。
- 一時的なキャッシュ効果を永続的なビューの違いから分離します。
- 新しいメッセージのテスト後に責任あるサインオフを要求します。
[ よくある質問 ]
よくある質問
スプリットホライズンDNSとは何ですか?
これは、名前空間のDNS応答がクエリのソースまたはその他のビュー選択属性に応じて異なる構成です。内部クライアントと外部クライアントには異なるゾーン データが表示される場合があります。
受信者がDKIM検証できないのにオフィス検索が成功するのはなぜですか?
オフィスは、公的権限が及ばないキーを含むプライベートゾーンを照会する場合があります。これが原因であると結論付ける前に、両方のビューでメッセージからの正確なセレクター所有者を比較してください。
待っていると常に社内の回答と公開の回答が一致しますか?
いいえ。意図的なビューの相違は、キャッシュされた回答のように期限切れになりません。不一致をキャッシュの問題として扱う前に、どの権限とビューが各結果を提供したかを確認してください。
ラップトップをフラッシュして受信者のキャッシュをクリアできますか?
いいえ。ローカル フラッシュでは、信頼できるデータや、キャッシュされた別のリゾルバーの肯定応答または否定応答は変更されません。関連するリゾルバーとタイミングの証拠をキャプチャします。
SERVFAIL 、 TXTレコードが欠落していることと同じですか?
いいえ。サーバー障害はエラーの結果であり、レコードが存在しないという正式な宣言ではありません。応答ステータスを保存し、解決パスを調査します。
プライベート ゾーン全体をパブリックDNSにコピーする必要がありますか?
いいえ。提案された運用計画では、外部ルートに必要な承認済みの認証レコードのみが公開されます。プライベート サービスとアドレスは、意図的に非公開のままにすることができます。
どのSPF所有者を比較する必要がありますか?
メッセージに対して評価されたSMTP ID (通常はエンベロープ送信者ドメイン) を使用します。表示されている From ドメインで便利なTXTレコードを比較すると、間違った所有者を調査できる可能性があります。
[ 情報源 ]
情報源
- RFC9499
セクション §6. DNSサーバーとクライアント · §7.ゾーン
- Microsoft: スプリットブレインDNS導入
セクション スプリット ブレインDNS展開 · ゾーン スコープとDNSクエリ解決ポリシー
- RFC1034
セクション §4.2.1 技術的考慮事項 · §4.2.2 管理上の考慮事項 · §4.3.2 アルゴリズム
- RFC2308
セクション §2.否定的な反応 · §5。否定的な回答のキャッシュ
- RFC1035
セクション §3.3.11 NS RDATA フォーマット · §3.3.13 SOA RDATA フォーマット · §4.1 メッセージフォーマット
- RFC7208
セクション §4. SPF評価 · §4.5 レコードの選択 · §4.6.4 DNSルックアップ制限
- RFC9989
セクション 識別子の調整 · DMARCポリシーの検出
- RFC6376
セクション §3.5 DKIM-Signatureヘッダー フィールド · §3.6 鍵の管理と表現 · §6。検証者のアクション
[ 用語集 ]
用語集
企業の来歴
一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。
従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。
EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。
SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化