DNSSEC検証チェッカー
ドメインのDNSKEYレコードをGoogle・Cloudflare等複数の公開DNSリゾルバーへ問い合わせ、DNSSECの署名チェーンが正しく検証されているかを診断します。
Tips
- AD（Authenticated Data）フラグは、問い合わせたDNSリゾルバー自身がDNSSEC検証を行った場合にのみ立ちます。リゾルバーがDNSSECに対応していない場合は正しく判定できません。
- 「DNSSEC未導入」は異常ではありません。多くのドメインは今もDNSSECを使っておらず、これは検索順位やメール到達性に直接影響しません。
- 「検証失敗」と判定された場合、まず親ゾーン（レジストラ管理画面）に登録したDSレコードのキータグ・ダイジェストが、現在のDNSKEYと一致しているか確認しましょう。
- DNSSECの署名には有効期限（RRSIGのExpiration）があります。ゾーン管理ソフトの自動再署名が止まっていないかも確認対象です。
- DNSSECを新たに有効化した直後は、親ゾーンへのDS登録が反映されるまでの間、一時的に「検証失敗」と表示される場合があります。
よくある質問
余談ですが ― 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）が別途保護されていることが前提です。