キャッシュDNSサーバのDNSSEC対応：DNSSEC再入門（3）（1/2 ページ）

DNSSECで検証可能なドメイン名が広がる

　2011年3月31日（協定世界時）に.comゾーンのDSレコードがルートゾーンに登録・公開され、DNSSEC（Domain Name System Security Extensions：DNSセキュリティ拡張）による検証ができるようになった。また、ccTLDで最大の登録数を擁する.deのレジストリであるDENICが、2011年5月31日にDSレコードをルートゾーンに登録する予定であると表明した。

　これにより、ドメイン名登録数で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が含まれた行のみを抽出する。

　この行を、root-anchors.keyとして保存しておく。

　次に、入手したトラストアンカー（root-anchors.key）を検証する。ここでは例として、PGPの実装の1つであるGnuPG（The GNU Privacy Guard）を用いた方法を示す。トラストアンカーの検証は、次のステップで行う。

【1】IANAのPGP公開鍵の入手

　https://data.iana.org/root-anchors/icann.pgpより、IANAのPGP公開鍵を入手する（注1）。そして、入手したicann.pgpを次のコマンドでインポートする。

【2】IANAのPGP公開鍵の検証

　入手したIANAのPGP公開鍵について、鍵IDとフィンガープリントを確認する。

　「0F6C91D2」がPGP公開鍵の鍵ID、「Key fingerprint = 」に続く16進数が鍵のフィンガープリントである。

　次に、鍵IDを基に複数のPGP公開鍵サーバで検索し、一致していることを確認する。ここでは、確認をより確実なものとするため、pgp.nic.ad.jpとpgp.mit.eduの2つの公開鍵サーバで公開されている鍵と照合している。

　下線で示したフィンガープリントが一致すれば、「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レコード形式）の検証

　次のコマンドを実行し、署名の検証を行う。

　上記の「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コマンドを利用する。

　4列目の鍵タグ（この例では、19036）と、7列目のDSレコード形式のトラストアンカー（この例では、49AAで始まる文字列）が、root-anchors.xmlに記載されている「KeyTag」「Digest」と一致することを確認する。なお、DSレコード形式の文字列に含まれる空白は、あらかじめ取り除いておく。

　root-anchors.xmlの内容とコマンドの出力が一致すれば、入手したトラストアンカーは正しいものであると判断できる。