Interactive

DNSSEC検証チェーン可視化

DNSSECは、DNSの応答が改ざんされていないことを暗号署名で保証する仕組みです(暗号化はしません)。 検証リゾルバ・ルート・.com・example.comの4者間で、DS→DNSKEY→RRSIGの鎖をルートのトラストアンカーから1段ずつ検証する様子をステップ再生できます。 正常に検証が通るSecure、 署名不一致で応答が破棄されるBogus、 最初から未署名で検証対象外と正しく判定されるInsecure—— DNSSECの検証結果が持つ3つの状態を、それぞれ体感できます。

ルート→.com→example.comと、DS・DNSKEY・RRSIGの鎖を1段ずつ検証してAD=1にたどり着く

検証リゾルバルートKSKをトラストアンカーとして保持ルート(.).comexample.com1. 問い合わせ:DNSKEY .2. DNSKEY(KSK, ZSK) + RRSIG(DNSKEY)(署名者=ルートKSK)3. ルートのDNSKEYをトラストアンカーと照合4. 問い合わせ:DS com5. DS(com) + RRSIG(DS)(署名者=ルートZSK)6. RRSIG(DS)をルートのDNSKEY(ZSK)で検証7. 問い合わせ:DNSKEY com8. DNSKEY(KSK, ZSK) + RRSIG(DNSKEY)(署名者=comのKSK)9. .comのDNSKEYをDS(com)と突き合わせ、自己署名も検証10. 問い合わせ:DS example.com11. DS(example.com) + RRSIG(DS)(署名者=comのZSK)12. RRSIG(DS)を.comのDNSKEY(ZSK)で検証13. 問い合わせ:DNSKEY example.com14. DNSKEY(KSK, ZSK) + RRSIG(DNSKEY)(署名者=example.comのKSK)15. example.comのDNSKEYをDS(example.com)と突き合わせ、自己署名も検証16. 問い合わせ:A www.example.com17. A = 93.184.216.34 + RRSIG(A)(署名者=example.comのZSK)18. RRSIG(A)をexample.comのDNSKEY(ZSK)で検証19. 検証完了:Secure(AD=1)
前提問い合わせ応答検証判定
1 / 19
問い合わせ検証リゾルバルート(.)

1. 問い合わせ:DNSKEY .

DNSKEY .

DNSKEY . をこのゾーンの権威サーバーに問い合わせる。

ここが分かる

  • 各ゾーンで検証の型は同じ——親が署名した DS が子のKSKのハッシュと一致するか確認し、KSKで鍵束(DNSKEY RRset)の自己署名を検証し、ZSKで実データを検証する。この3段セットをルートから目的のドメインまで繰り返すだけ。
  • 攻撃者が応答を差し替えても、正しい秘密鍵(ZSK)を持っていない限り新しい正しい署名は作れない——だから改ざんは必ずRRSIGの検証で弾かれる(Bogus検証系シナリオ)。
  • 「DSが無い」という否定の応答にもNSEC/NSEC3で署名がつく——これが無いと、攻撃者はDSを消すだけでDNSSEC自体を無効化できてしまう(ダウングレード攻撃)。だからInsecureは安全に判定できる。
  • 検証結果は3状態:Secure(AD=1)・Bogus(SERVFAILで遮断)・Insecure(AD=0だがエラーではない)。「署名が無い」と「署名が壊れている」は明確に区別される。