次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（2/3 ページ）
現在、標準化作業が進行中のDNSSEC。その仕組みとBIND 9での実現方法を解説する。後半では、スプリットDNSの設定方法を紹介。（編集局）
BIND 9によるDNSSECの実現
BIND 9.2.2以降で使用できるDNSSECはDS方式のみで、RFC 2535方式は使用できません。
DS方式で鍵の作成とゾーンの署名を行ってみましょう。ただし、上位ドメインにDSレコードを登録する手順が現時点ではないため、ZSK鍵への署名とDSレコードの登録方法については言及しません。
BIND 9の再インストール
BIND 9は、標準インストールではDNSSECに対応していないため、再インストールが必要です。RPMなどのパッケージも同様にDNSSEC対応版が必要ですが、ほとんどのディストリビューションでは用意されていないため、ソースからコンパイルする必要があります。
configure実行時に--with-opensslでOpenSSL（http://www.openssl.org/）のインストール先を指定します。通常は/usrですが、OpenSSLをソースからインストールした場合は/usr/localになっている場合もあります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
named.confやゾーンファイルは通常どおりに用意します（参考：第2回）。DNSSECのための作業はここでは特に必要ありません。
鍵ペアの作成と設定
次に、ZSK鍵のペアを作成します。作業は/var/namedで行います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
暗号アルゴリズム、鍵の長さは任意のもので構いませんが、KSK鍵を作成する際は更新頻度を考え、鍵の長さは十分大きな値に設定します。
ここまでの作業で、鍵の名前.key、鍵の名前.privateファイルの対ができます。*.keyが公開鍵、*.privateが秘密鍵です。*.keyファイルは、ゾーン情報に登録できるようにフォーマットされています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ZSK鍵の公開鍵をゾーンファイルに記述します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
準備ができたら、ゾーンファイルに署名します。すでに運用に入っているゾーンファイルの場合は、先にSOAレコード中のSerial値を上げておきます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
以上の作業により、以下のようなゾーンファイルが作成されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
作成した署名済みゾーンファイル（example.zone.signed）を現在のゾーンファイルに置き換え、
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
やnamedの再起動でゾーン情報を更新すれば作業終了です。
KEY／SIG／NXTレコード
DNNSECは仕組みが多少複雑ですが、実際のゾーンファイルの作成は上記のようにdnssec-signzoneコマンドで、ほぼ自動で行えます。署名後のゾーンファイルを見ると、新しい資源レコードが追加されているのが分かります。
- KEYレコード：公開鍵を指定
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
| 256： | ゾーン鍵の場合は256、それ以外は0 |
|---|---|
| 3： | DNSSECのプロトコル番号「3」 |
| 1： | 鍵を作成した暗号アルゴリズム。RSA/MD5は「1」。Diffie-Hellmanは「2」、DSA/SHA-1は「3」、RSA/SHA-1は「5」 |
| (公開鍵)： | Base64でエンコードされた公開鍵 |
| 32394： | 鍵id。Kexample.jp.+001+32394のように、使用された鍵の名前の最終フィールドが鍵idになる |
- SIGレコード：レコードに対する署名を指定
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
| A： | 署名を行ったレコード。例ではdns.example.jp.のAレコードに対して署名が行われている |
|---|---|
| 1： | 使用した暗号アルゴリズム。KEYレコードと同様 |
| 3： | dns、example、jpのように、オーナーが3ラベルで構成されていることを指定 |
| 86400： | TTL |
| 20040315175332： | 署名の有効期限。YYYYMMDDHHMMSSフォーマットを使用 |
| (署名)： | Base64でエンコードされた署名 |
- NXTレコード：次に来るレコードを指定
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の例では、dns.example.jpの次にpc1.example.jpのAレコードが来ることが分かります。こうすることで、（dns2やpc0などの）レコード名が存在しないことも保証できます。
今回使用したゾーンファイルの例では、example.jp→dns.example.jp→pc1→pc2→pc3→pc4→pc5（注）の順で記述されています。
署名されたゾーンファイルのNXTレコードを見ると、その連鎖順（注）も同じように作られ、最後はpc5→example.jpに戻っています。ドメイン名で連鎖を作り、さらに循環させることで、連鎖の間にはいかなるドメイン名も存在しないことを保証しています。例えば、dns.example.jpの次にpc1.example.jpのAレコードが来るため、dns0.example.jpやdns1.example.jpのようなドメイン名は存在が否定されます。
DNSSEC普及の課題
BIND 9におけるDS方式への変更など、DNSSECにはまだ発展途上の感があり、普及には時間を要すると思われます。また、下位ゾーンから送られてくる公開鍵を上位ゾーンが確認する際に、いかに出元の保証を行うかなど、まだまだ検討の余地が残されています。何より、現在動いているシステムをどのように新しいものに置き換えるのか。IPv6と同様、大変重要な課題です。
Copyright © ITmedia, Inc. All Rights Reserved.