権威DNSサーバのDNSSEC対応：DNSSEC再入門（4）（3/4 ページ）

[坂口智哉，株式会社日本レジストリサービス（JPRS）]

権威DNSサーバの構築

　今回は、DNSSEC設定の手間を軽減するためのBINDの機能「Smart signing」を使った権威DNSサーバの構築例を紹介する。構築する権威DNSサーバのパラメータは、前述のJPドメイン名と同様のパラメータを用いることとし、ドメイン名はexample.jpとする。

　表3は、今回前提とするパラメータをまとめたものである。

パラメータ	内容
ドメイン名	example.jp
naemdのベースディレクトリ	/var/named/
KSK、ZSKを保管するディレクトリ	/var/named/keys
ゾーンファイルを保管するディレクトリ	/var/named/zone
既存のゾーンファイル	/var/named/zone/example.jp.zone
namedの設定ファイル	/var/named/named.conf
不在証明の方式	NSEC3
SOAシリアル番号表記	unixtime
鍵のアルゴリズム（KSK）	RSASHA256
鍵長（KSK）	2048bit
鍵のアルゴリズム（ZSK）	RSASHA256
鍵長（ZSK）	1024bit
署名有効期間（KSK）	おおむね2カ月
署名有効期間（ZSK）	おおむね1カ月
再署名の間隔（KSK）	1カ月ごと
再署名の間隔（ZSK）	1週間ごと
キーロールオーバー（ZSK）	1カ月ごと／事前公開法
キーロールオーバー（KSK）	1年ごと／二重署名法
表3　構築例におけるパラメータ

　権威DNSサーバをDNSSECに対応させるには下記のステップを踏むとよい。

［STEP1］KSK、ZSKを作成する

［STEP2］ゾーンへ署名を行う

［STEP3］namedの設定を変更する

［STEP4］DSレコードの登録依頼を行う

　なお、設定の前提として、DNSSECに対応させる予定のドメイン名のレジストリやレジストラ（JPドメイン名では指定事業者）がDNSSECに対応している必要がある。当該ドメイン名がDNSSECに対応しているかどうかは、レジストリやレジストラに問い合わせて確かめてみるとよいだろう。

【STEP1】KSK、ZSKを作成する

　BINDでは、KSKとZSKはdnssec-keygenコマンドを用いて作成する。

$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20111201000000 -A 20111201000000 -I 201212310000 example.jp

KSKの作成例

$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111201000000 -A 20111201000000 -I 20111231235959 example.jp

ZSKの作成例

　ここでは、dnssec-keygenコマンド自体の説明は省略するが、作成例で使用しているオプションはそれぞれ以下のような意味を持つ。

オプション	意味
-K	鍵の作成場所を指定
-a	アルゴリズム名を指定
-b	鍵長を指定
-r	乱数生成元を指定
-f	鍵のフラグを指定（KSKの場合のみ）
-P	鍵を公開する日時を指定（YYYYMMDDhhmmss）
-A	その鍵で署名を開始する日時を指定（YYYYMMDDhhmmss）
-I	その鍵で署名することをやめる日時を指定（YYYYMMDDhhmmss）

　つまり、作成例におけるKSKは、2011年12月1日0時0分0秒から公開かつ署名に使われ、13カ月後の2012年12月31日23時59分59秒から、署名には使われなくなることを意味する。同様にZSKも、2011年12月1日0時0分0秒から公開かつ署名に使われ、1カ月後の2011年12月31日23時59分59秒に署名に使われなくなるということである。

　コマンドを実行すると、/var/named/keysの下に合計で4つのファイルが生成されているはずだ。

$ ls -l /var/named/keys
Kexample.jp.+008+20329.key
Kexample.jp.+008+20329.private
Kexample.jp.+008+32349.key
Kexample.jp.+008+32349.private

　末尾が.keyとなっているのが公開鍵、.privateとなっているのが秘密鍵であり、KSKとZSKを作成したので、2セットが作成されている。またファイル名の「008」の部分はアルゴリズムがRSASHA256であることを表しており、「20329」や「32349」となっている部分が、「鍵タグ」と呼ばれる、それぞれの鍵を識別するための固有の番号である。

　注意点として、ファイル名だけでは、どちらがKSKでどちらがZSKなのか区別がつかないことが挙げられる。そのような場合は.keyのファイルの中身を開いてみるとよい。ZSKには「zone-signing key」、KSKには「key-signing key」と記述されているので、それで区別できる。今回の例では、「20329」がKSK、「32348」がZSKとする。

【STEP2】ゾーンへ署名を行う

　STEP1で作成した鍵を使って、実際にゾーンファイルに署名を付加する。これは、dnssec-signzoneコマンドを用いる。

$ dnssec-signzone -a -S -x -K /var/named/keys -d /var/named/zone -3 1234 -e +30d -r /dev/urandom -N unixtime -f /var/named/zone/example.jp.signed -o example.jp /var/named/zone/example.jp.zone

署名の例

　それぞれオプションは以下のような意味を持つ。

オプション	意味
-a	生成した署名の整合性をチェックする
-S	Smart signingの機能を使用する
-x	DNSKEYレコードに対してはKSKのみで署名を行う
-K	鍵が保管されている場所を指定
-d	DSレコードのセットを生成する場所を指定
-3	NSEC3のSALTを指定
-e	署名の有効期限の日時を指定
-r	乱数生成元を指定
-N	SOAのフォーマットをunixtimeでゾーンファイルを生成
-f	生成されるゾーンファイル名を指定
-o	ゾーン名を指定

　例では、既存のゾーンファイルexample.jp.zoneに対して、先ほど生成したKSKおよびZSKを用いて、署名を付加したデータをexample.jp.signedというファイル名で生成している。NSEC3のSALTについての説明はここでは省略するが、セキュリティ上の観点から毎回異なる値とするのが望ましい。

　これで、RRSIGやDNSKEYが加わった/var/named/zone/example.jp.signedというゾーンファイルが生成されているはずだ。