[ DNSとドメイン ]

複数の権威ネームサーバーからの応答を比較する

権威サーバー間で正確なレコード セットを比較し、実際の出版物の違いと無害な回答の順序を区別します。

EmailAuth研究チームによる

【ポイント】

  • 各アドバタイズされた機関エンドポイントからの完全な応答を比較します。
  • TXT文字列の境界を変更せずにレコードセットの順序を正規化します。
  • SOA シリアルの一致は、ゾーンの内容の一致を証明するものではありません。
このページでは

さまざまな権威サーバーは、サービスを提供するゾーンの一貫したビューを提供する必要があります。認証チェックが一致しない場合は、同じ所有者、タイプ、およびクラスについて、公開されている各機関を照会します。応答を正規化する前に、未編集の応答を保持します。値の簡潔なリストにより、参照、エラー、および欠落している権限フラグを隠すことができます。

どのサーバーが重要かを確認する

参考文献: RFC 1034 §4.2, RFC 1035 §4.1.1.

親委任を読み取り、子頂点 NS セットと比較します。アドバタイズされたサーバー名をアドレスに解決し、どのアドレスが照会されたかを記録します。ホスト名には複数のアドレスを含めることができ、エニーキャストは同じアドレスを異なるインスタンスにルーティングできます。したがって、クエリが 1 回成功しただけでは、考えられるすべてのバックエンドが最新であることが証明されるわけではありません。

次のような直接的な非再帰クエリを使用します。 @SERVER_IP _dmarc.example .test を掘ります。 TXT +norecurse。応答コードと AA フラグ、応答セクションと権限セクション、およびエイリアスを検査します。信頼できると期待していたサーバーからの紹介または権限のない応答は、コンテンツが古い信頼できる応答とは異なります。

構造を破壊せずにデータを比較

参考文献: RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.

DNSレコードセットの順序付けはポリシーの優先順位ではありません。比較のために独立したレコード オブジェクトを並べ替えますが、各レコード内の文字列の順序は保持します。 TXTレコード。 TTL は、構成またはクエリのコンテキストによって異なる場合があります。黙って破棄するのではなく、記録してください。再帰的な TTL カウントダウンは、当局のゾーン構成であるかのように比較すべきではありません。

サポートコンテキストとして SOA をクエリします。 SOA シリアルはゾーンのハッシュではありません。シリアルの一致はレコードの一致を証明できません。また、シリアル演算がラップされるため、出力されたより大きな整数が常に新しいとは限りません。 RFC 1982では、シリアル スペースのちょうど半分の間隔での比較は未定義です。新しい/古い順序を強制しないでください。要求されたデータを直接比較し、プロバイダーの転送ログまたは公開ログを使用して相違点を説明します。

不一致と無害な並べ替えを再現する

example.test の 2 つの独立した権限を作成します。どちらも同じMXセットを公開しますが、そのレコードを異なる順序で返します。期待される正規化された比較は等しいです。次に権限Aを与えます _dmarc.example.test TXT "v=DMARC1; p=none" そしてB _dmarc.example.test TXT "v=DMARC1; p=reject"。両方の SOA シリアルが意図的に同じである場合でも、予期される比較は等しくありません。

同じタイプとオプションを使用して両方の権限を照会します。サーバーアドレス、タイムスタンプ、応答コード、フラグ、完全なレコード、シリアルを保存します。元のオフライン比較は、以下の保持されている履歴ループバック観察によって補足されています。パブリック ポリシーや運用DNSサーバーは変更されませんでした。

パブリケーションパスを修復する

参考文献: RFC 1034 §4.3.5, RFC 8767 §4.

1 つのサーバーが古いセカンダリであるか、廃止されたプロバイダーがまだ委任内に存在しているか、または目的の更新を受信して​​いない宛先であるかどうかを確認します。複数のパネルでランダムに編集を繰り返すのではなく、サポートされているパブリケーションまたは転送パスを修復します。変更後、テストされたすべての機関で同じ予想されるデータを確認します。

エニーキャストまたは分割ビューが疑われる場合は、関連するネットワークからの監視を繰り返します。意図的なビュー ポリシーと、偶発的な公開の不一致を区別します。権威ある合意だけでは、すでにキャッシュされた回答を削除したり、メッセージの認証を証明したりできないため、再帰的で代表的なメール証拠で終了します。

保存されている過去の研究室の証拠

保持されているキャプチャの日付は 2026 年 11 月 7 日です。以下では、 EmailAuth.aiの新しい実行やテストではなく、その限定された履歴観察について説明します。

2 つのループバック固定ゾーン認証局への実際の UDP クエリが返されました p=none そして p=reject 同じ絶対的なTXT所有者に対して。どちらの応答にも AA が設定されていました。キャプチャでは、各エンドポイント、UTC 時間、TTL、応答タイプ、コード、およびワイヤー バイトが保存されます。これは、実際に観察された研究室の不一致を示しています。パブリック エニーキャスト サービスは調査しません。キャプチャラベルはauthority_A_policyです。権限_B_ポリシー。保持されたランナーと生のキャプチャは、歴史的証拠としてこのレビュー パッケージに含まれています。それらは検査されたものであり、このレビューのために再実行されたものではありません。実稼働DNS 、 DNSSEC SMTP結果は未テストのままです。

[ 取り除く ]

SOA シリアルの一致は、ゾーンの内容の一致を証明するものではありません。

【役割別】

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

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

IT / メール管理者

構造化レコードを比較する

書式設定の違いにより、実際の不一致が隠蔽されたり誇張されたりする可能性があります。

次のステップ

  1. アドバタイズされた各エンドポイントをクエリします。
  2. フラグと応答コードを保持します。
  3. TXT境界をそのまま維持します。

CISO / SecOps

権威と信頼を区別する

権限のあるフラグは暗号の検証を証明するものではありません。

次のステップ

  1. 説明されていないビューを調査します。
  2. 生の証拠を保持します。
  3. DNSSEC個別に検証します。

創業者 / 非技術系

すべてのルートからの証拠を要求する

1 回の緑色の検索では、古い権限を見逃してしまう可能性があります。

次のステップ

  1. DNS所有権を割り当てます。
  2. プロバイダーの移行履歴を保持します。
  3. インシデントの終了基準を設定します。

[ よくある質問 ]

よくある質問

レコードの順序は重要ですか?

順序付けされていないDNSレコード セットを比較するためのものではありません。 1 つのレコード内のTXT文字列の順序は依然として重要です。

RFC 2181 §5 RFC 1035 §3.3.14

SOA シリアルが等しいことは、内容が等しいことを証明しますか?

いいえ。実際に要求されたレコードを比較してください。

RFC 1982 §3.2

+short を単独で使用する必要がありますか?

証拠収集のためではありません。フラグ、コード、セクションも保持します。

1 つのサーバー名で複数のエンドポイントを表すことはできますか?

はい。複数のアドレスに解決されるか、エニーキャストを使用する場合があります。

AAってどういう意味ですか?

回答には、関連するコンテキストでクエリされた名前に対して信頼できるマークが付けられます。 DNSSEC検証ではありません。

RFC 1035 §4.1.1

意図的なDNSビューが異なることはありますか?

はい。違いを偶然と呼ぶ前に、ビュー ポリシーとクエリの起点を文書化してください。

1 台のサーバーを修復すると再帰キャッシュはクリアされますか?

いいえ。以前にキャッシュされたデータは保持されます。

RFC 8767 §4

閉鎖の証拠は何ですか?

意図された典拠データの照合、説明された出版状態、およびフォローアップのリゾルバーとメールのチェック。

[ 情報源 ]

情報源

  1. RFC 1034

    セクション §4.2 · §4.3.5

  2. RFC 1035

    セクション §3.3.14 · §4.1.1

  3. RFC 1982

    セクション §3.2

  4. RFC 2181

    セクション §5

  5. RFC 8767

    セクション §4

  6. BIND 9 ディグマニュアル

    セクション クエリオプション

[ 用語集 ]

用語集

AAフラグ
DNS応答内の権威応答フラグ。

RFC 1035 §4.1.1

RRセット
同じ所有者、クラス、タイプを持つレコード。

RFC 2181 §5

エニーキャスト
同じサービス アドレスを異なるネットワークの場所にルーティングします。

企業の来歴

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

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

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

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

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

ナレッジベース