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

インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部）

[阿波連良尚，株式会社日本レジストリサービス（JPRS）]

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による検証が可能な状態となっている。

【関連記事】

JPドメイン名がいよいよDNSSECに対応

http://www.atmarkit.co.jp/news/201101/17/jprs.html

　今回は、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が含まれた行のみを抽出する。

$ dig . DNSKEY | grep -w DNSKEY | grep -w 257 > root-anchors.key $ cat root-anchors.key .                    172800  IN      DNSKEY  257 3 8 AwEAAag【中略】Uk1ihz0=

ルートゾーンののDNSKEYレコードの取得

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

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

1. IANAのPGP公開鍵の入手
2. IANAのPGP公開鍵の検証
3. トラストアンカー（DSレコード形式）と署名の入手
4. IANAのPGP公開鍵によるトラストアンカー（DSレコード形式）の検証
5. トラストアンカーのDNSKEYレコード形式からDSレコード形式への変換と比較

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

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

$ gpg --import icann.pgp gpg: key 0F6C91D2: public key "DNSSEC Manager <[e-mail]>" imported gpg: Total number processed: 1 gpg:               imported: 1

PGP公開鍵のインポート

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

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

$ gpg --fingerprint [e-mail] pub  1024D/0F6C91D2 2007-12-01 DNSSEC Manager <[e-mail]>      Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2 sub  2048g/1975679E 2007-12-01

PGP公開鍵の鍵IDとフィンガープリントの確認

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

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

$ gpg --search-keys --interactive --keyserver pgp.nic.ad.jp 0x0F6C91D2 gpg: searching for "0x0F6C91D2" from HKP server pgp.nic.ad.jp Keys 1-1 of 1 for "0x0F6C91D2" (1)     DNSSEC Manager <[e-mail]>         1024 bit DSA key 0F6C91D2, created 2007-11-30 Enter number(s), N)ext, or Q)uit > 1 pub 1024D/0F6C91D2 created: 2007-12-01 expires: never         Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2         DNSSEC Manager <[e-mail]> Do you want to import this key? (y/N) N gpg: Total number processed: 1

PGP公開鍵のフィンガープリントの照合（1）

$ gpg --search-keys --interactive --keyserver pgp.mit.edu 0x0F6C91D2 gpg: searching for "0x0F6C91D2" from HKP server pgp.mit.edu Keys 1-1 of 1 for "0x0F6C91D2" (1)     DNSSEC Manager <[e-mail]>         1024 bit DSA key 0F6C91D2, created 2007-11-30 Enter number(s), N)ext, or Q)uit > 1 pub  1024D/0F6C91D2 created: 2007-12-01 expires: never         Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2         DNSSEC Manager <[e-mail]> Do you want to import this key? (y/N) N gpg: Total number processed: 1

PGP公開鍵のフィンガープリントの照合（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 --verify root-anchors.asc root-anchors.xml gpg: Signature made Wed Jul 7 07:49:10 2010 JST using DSA key ID 0F6C91D2 gpg: Good signature from "DNSSEC Manager <[e-mail]>" gpg: WARNING: This key is not certified with a trusted signature! gpg:          There is no indication that the signature belongs to the owner. Primary key fingerprint: 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2

root-anchors.xmlに対する署名の検証

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

$ dnssec-dsfromkey -a SHA-256 -f root-anchors.key . . IN DS 19036 8 2 49AAC11D【略】

トラストアンカー（DSレコード形式）への変換

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

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

注1：本稿執筆時点で、IANAのWebサーバから入手できるPGP公開鍵の有効期限が切れており、検証の際に注意を促すメッセージが表示される。ルートゾーンの署名鍵の有効期限が切れているわけではないので、ルートゾーンのDNSSECでの検証には問題ない。