キャッシュDNSサーバのDNSSEC対応：DNSSEC再入門（3）（1/2 ページ）
インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部）
DNSSECで検証可能なドメイン名が広がる
2011年3月31日（協定世界時）に.comゾーンのDSレコードがルートゾーンに登録・公開され、DNSSEC（Domain Name System Security Extensions：DNSセキュリティ拡張）による検証ができるようになった。また、ccTLDで最大の登録数を擁する.deのレジストリであるDENICが、2011年5月31日にDSレコードをルートゾーンに登録する予定であると表明した。
【関連リンク】
DENICのプレスリリース（英文）
「Yes to Secure Internet! - DNSSEC Is Coming for .de: www.denic.de」
http://www.denic.de/en/denic-in-dialogue/press-releases/press/3116.html
これにより、ドメイン名登録数で1位と2位のTLDがDNSSECに対応することとなった。なお、.jpゾーンについては、2010年12月10日にDSレコードがルートゾーンに登録・公開され、DNSSECによる検証が可能な状態となっている。
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。
DNSSECにおけるキャッシュDNSサーバの役割
キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。
第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。
DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラストアンカーとして設定する。これによって、ルートゾーンからDNSSECにおける信頼の連鎖が構築されているすべてのゾーンについて検証を行うことが可能となる。
ルートゾーンのトラストアンカーの入手と確認方法
前節で説明したとおり、トラストアンカーは、信頼の連鎖の起点となる重要な情報である。このため、入手したトラストアンカーが正しいものであることを確認する必要がある。
トラストアンカーは、KSK（Key Signing Key：鍵署名鍵）の公開鍵、またはそれを元に生成されたハッシュの形で提供される。公開鍵の場合はDNSKEYレコードの形で、ハッシュの場合はDSレコードの形で提供される。
まず、digコマンドを用いてルートゾーンのDNSKEYレコードを取得する。「.」（ルートゾーン）のDNSKEYレコードを問い合わせ、結果からKSKが含まれた行のみを抽出する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この行を、root-anchors.keyとして保存しておく。
次に、入手したトラストアンカー（root-anchors.key）を検証する。ここでは例として、PGPの実装の1つであるGnuPG（The GNU Privacy Guard）を用いた方法を示す。トラストアンカーの検証は、次のステップで行う。
- IANAのPGP公開鍵の入手
- IANAのPGP公開鍵の検証
- トラストアンカー（DSレコード形式）と署名の入手
- IANAのPGP公開鍵によるトラストアンカー（DSレコード形式）の検証
- トラストアンカーのDNSKEYレコード形式からDSレコード形式への変換と比較
【1】IANAのPGP公開鍵の入手
https://data.iana.org/root-anchors/icann.pgpより、IANAのPGP公開鍵を入手する（注1）。そして、入手したicann.pgpを次のコマンドでインポートする。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
【2】IANAのPGP公開鍵の検証
入手したIANAのPGP公開鍵について、鍵IDとフィンガープリントを確認する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「0F6C91D2」がPGP公開鍵の鍵ID、「Key fingerprint = 」に続く16進数が鍵のフィンガープリントである。
次に、鍵IDを基に複数のPGP公開鍵サーバで検索し、一致していることを確認する。ここでは、確認をより確実なものとするため、pgp.nic.ad.jpとpgp.mit.eduの2つの公開鍵サーバで公開されている鍵と照合している。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
下線で示したフィンガープリントが一致すれば、「PGP公開鍵が同一のものである」と検証できたことになる。
【3】トラストアンカー（DSレコード形式）と署名の入手
https://data.iana.org/root-anchors/root-anchors.xmlからルートゾーンのトラストアンカー（DSレコード形式）を、https://data.iana.org/root-anchors/root-anchors.ascからその署名を入手する。
【4】IANAのPGP公開鍵によるトラストアンカー（DSレコード形式）の検証
次のコマンドを実行し、署名の検証を行う。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の「gpg: Good signature from "DNSSEC Manager
【5】トラストアンカーのDNSKEYレコード形式からDSレコード形式への変換と比較
root-anchors.xmlには、DSレコード形式のトラストアンカーが記載されている。しかし、BIND 9ではトラストアンカーをDNSKEYレコード形式で登録する必要がある。このため、入手したトラストアンカーをDNSKEYレコード形式からDSレコード形式に変換し、root-anchors.xmlに記載されているものと一致しているか確認する必要がある。
DNSKEYレコード形式からDSレコード形式への変換は、BIND 9に付属するdnssec-dsfromkeyコマンドを利用する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
4列目の鍵タグ（この例では、19036）と、7列目のDSレコード形式のトラストアンカー（この例では、49AAで始まる文字列）が、root-anchors.xmlに記載されている「KeyTag」「Digest」と一致することを確認する。なお、DSレコード形式の文字列に含まれる空白は、あらかじめ取り除いておく。
root-anchors.xmlの内容とコマンドの出力が一致すれば、入手したトラストアンカーは正しいものであると判断できる。
注1：本稿執筆時点で、IANAのWebサーバから入手できるPGP公開鍵の有効期限が切れており、検証の際に注意を促すメッセージが表示される。ルートゾーンの署名鍵の有効期限が切れているわけではないので、ルートゾーンのDNSSECでの検証には問題ない。
Copyright © ITmedia, Inc. All Rights Reserved.