連載
» 2011年06月01日 00時00分 公開

DNSSEC再入門(3):キャッシュDNSサーバのDNSSEC対応 (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 <dnssec@iana.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
PGP公開鍵のインポート

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

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

$ gpg --fingerprint dnssec@iana.org
pub  1024D/0F6C91D2 2007-12-01 DNSSEC Manager <dnssec@iana.org>
     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 <dnssec@iana.org>
        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 <dnssec@iana.org>

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 <dnssec@iana.org>
        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 <dnssec@iana.org>

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 <dnssec@iana.org>"
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での検証には問題ない。


       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。