DNSSEC検証チェッカー

ドメインのDNSKEYレコードをGoogle・Cloudflare等複数の公開DNSリゾルバーへ問い合わせ、DNSSECの署名チェーンが正しく検証されているかを診断します。

DNSSECの署名チェーンを診断する

ドメインの DNSKEY レコードを複数の公開リゾルバーへ問い合わせ、DNSSEC の署名の連なりが正しく検証されているかを診断します。DNSSEC を有効にしたつもりが途中で切れている、という状態を見つけられます。

**DNSSEC が守るのは「答えが改ざんされていないこと」であって、「内容が秘密であること」ではありません。** 通信の中身は従来どおり誰にでも見え、保証されるのは真正性だけです。**そして最も多い設定漏れが、親ゾーンへの DS レコードの登録忘れです。** 自分のゾーンに鍵を置いて署名しても、**レジストラを通じて親(`.com` など)へ DS を登録しなければ、信頼の連なりはそこで途切れて検証されません。** 逆に、鍵のロールオーバーに失敗して不整合が起きると、**検証するリゾルバーからはドメイン全体が引けなくなります。** 中途半端な状態は、有効にしていない状態より危険になりうるということです。

使い方

  1. ドメインを入力する `example.com` のように、ドメインだけを入れます。
  2. 検証の結果を読む **署名の連なりが親までつながっているかが判定されます。**
  3. DSレコードの有無を確かめる **ここが抜けていると、鍵を置いていても検証されません。**
  4. 複数のリゾルバーの答えを比べる 食い違いがあれば、キャッシュか設定のどちらかを疑えます。

使いこなすためのヒント

  • AD(Authenticated Data)フラグは、問い合わせたDNSリゾルバー自身がDNSSEC検証を行った場合にのみ立ちます。リゾルバーがDNSSECに対応していない場合は正しく判定できません。
  • 「DNSSEC未導入」は異常ではありません。多くのドメインは今もDNSSECを使っておらず、これは検索順位やメール到達性に直接影響しません。
  • 「検証失敗」と判定された場合、まず親ゾーン(レジストラ管理画面)に登録したDSレコードのキータグ・ダイジェストが、現在のDNSKEYと一致しているか確認しましょう。
  • DNSSECの署名には有効期限(RRSIGのExpiration)があります。ゾーン管理ソフトの自動再署名が止まっていないかも確認対象です。
  • DNSSECを新たに有効化した直後は、親ゾーンへのDS登録が反映されるまでの間、一時的に「検証失敗」と表示される場合があります。

活用シーン

DNSSECを有効にしたあとの確認

**設定画面で有効にしただけでは完了していないことが多くあります。**

鍵のロールオーバーを見届ける

鍵を入れ替えた前後で、検証が途切れていないかを確かめられます。

名前が引けない原因を切り分ける

**DNSSEC の不整合は、一部の利用者からだけドメインが消えたように見えます。**

取引先のドメインを調べる

相手がどこまで対策しているかを知る材料になります。

DNSSECの用語

DNSKEY
ゾーンの公開鍵を置くレコードです。署名の検証に使われます。
DSレコード
**子ゾーンの鍵の指紋を、親ゾーンに登録するレコードです。** これが無いと信頼の連なりが途切れます。
RRSIG
各レコードに付けられた署名そのものです。有効期限を持ち、定期的に更新されます。
信頼の連なり
ルートから親、子へと署名が連なる構造です。**一箇所でも途切れると検証できません。**
鍵のロールオーバー
鍵を新しいものへ入れ替える作業です。**手順を誤ると、ドメイン全体が引けなくなります。**
検証するリゾルバー
DNSSECの署名を実際に確かめるリゾルバーです。**不整合があると、ここからは答えが返りません。**

よくある質問

「DNSSEC未導入」自体は危険ではありません。現在も大多数のドメインがDNSSECなしで運用されています。ただしDNSキャッシュポイズニング対策として、可能であれば導入を検討する価値はあります。

DNSSECに対応したリゾルバー(多くの企業ネットワークや一部ISP)を使っているユーザーは、そのドメインを名前解決できなくなる可能性があります(SERVFAILとして扱われる)。導入直後・DS登録の反映待ちの場合を除き、早急な修正が必要です。

各リゾルバーが同時にキャッシュを持っている場合、DNSKEYの更新(ロールオーバー)直後は一時的に新旧の鍵が混在し、リゾルバーによって検証結果が異なることがあります。時間を置いて再度チェックしてください。

異なります。DNSSECは「名前解決の応答が改ざんされていないか」を保証する仕組みで、SSL/TLSは「通信内容が暗号化され、接続先が証明書の持ち主であるか」を保証する仕組みです。両者は独立していて、片方だけを導入している状態もあり得ます。

このツールはDNSKEYの公開有無とリゾルバーのAD判定という表層的な状態のみを確認します。厳密な署名チェーンの解析(RRSIG・NSEC/NSEC3の整合性等)が必要な場合は、dnsviz.net等の専門ツールを併用してください。
ツールくん

余談ですが ― DNSに「なりすまし」を防ぐ仕組みを足した経緯

DNSは1983年の設計当初、応答の送信元を暗号学的に確認する手段を持っていませんでした。リゾルバーは「それらしいIDが付いたUDPパケットが返ってきたら信じる」という性善説のプロトコルであり、送信元IPの詐称やパケットの推測が可能であれば偽の応答を注入できてしまいます。2008年にセキュリティ研究者Dan Kaminskyが発見した「Kaminsky攻撃」は、この弱点を突いてキャッシュポイズニング(偽のレコードをリゾルバーのキャッシュに注入する攻撃)を実用的な速度で行えることを示し、業界に衝撃を与えました。

DNSSEC(DNS Security Extensions)はこの問題への回答として標準化された拡張で、公開鍵暗号を使い「この応答は正規のゾーン管理者が署名したものである」ことを証明します。ドメインのDNSKEYで応答に電子署名を行い、親ゾーンに登録したDSレコードがそのDNSKEYのダイジェストを保証することで、ルートゾーンから末端のドメインまでの「信頼の連鎖(Chain of Trust)」を構築します。

DoH(DNS over HTTPS)レスポンスに含まれる「AD(Authenticated Data)」フラグは、このDNSSEC検証をリゾルバー自身が代行した結果です。ブラウザやアプリが個別に署名検証を実装しなくても、信頼できるリゾルバーに問い合わせてAD=trueが返れば、応答が改ざんされていないことを間接的に確認できます。ただしこれはリゾルバーとアプリ間の通信経路(HTTPS)が別途保護されていることが前提です。