次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（2/3 ページ）

» 2004年02月24日 00時00分公開

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になっている場合もあります。

# wget ftp://ftp.isc.org/isc/bind9/9.2.3/bind-9.2.3.tar.gz　←最新のBINDを入手

# tar xvfz bind-9.2.3.tar.gz

# cd bind-9.2.3/

# ./configure --with-openssl=/usr

注：この場合、namedやdigなどのバイナリは/usr/localにインストールされます。--prefixで変更できますが、named.confの指定位置も変わります。

# make

# make install

注：PGP Signatureによるソースファイルの検証などについては、第1回を参照。

　named.confやゾーンファイルは通常どおりに用意します（参考：第2回）。DNSSECのための作業はここでは特に必要ありません。

鍵ペアの作成と設定

　次に、ZSK鍵のペアを作成します。作業は/var/namedで行います。

# /usr/local/sbin/dnssec-keygen -a RSA -b 1024 -n ZONE example.jp

Kexample.jp.+001+32394　←作成された鍵の名前の例

注：マシンパワーによっては数分かかります。コマンドパスおよびexample.jpは適宜書き換えてください。

	dnssec-keygenのオプション
	-a	RSA、DSAなどの暗号アルゴリズムを指定
	-b	鍵の長さを指定
	-n	ZONE、HOST、ENTITY、USERが指定可能。ここではHOSTを指定

　暗号アルゴリズム、鍵の長さは任意のもので構いませんが、KSK鍵を作成する際は更新頻度を考え、鍵の長さは十分大きな値に設定します。

　ここまでの作業で、鍵の名前.key、鍵の名前.privateファイルの対ができます。*.keyが公開鍵、*.privateが秘密鍵です。*.keyファイルは、ゾーン情報に登録できるようにフォーマットされています。

# ls K*

Kexample.jp.+001+32394.key

Kexample.jp.+001+32394.private



# more Kexample.jp.+001+32394.key

example.jp. IN KEY 256 3 1 AQPOnBAUz……（省略）

注：ファイルの名前は一例です。

　ZSK鍵の公開鍵をゾーンファイルに記述します。

# cat Kexample.jp.+001+32394.key >> /var/named/example.zone

注：ファイル名は各自の環境に合わせて適宜書き換えてください。

　準備ができたら、ゾーンファイルに署名します。すでに運用に入っているゾーンファイルの場合は、先にSOAレコード中のSerial値を上げておきます。

# dnssec-signzone -o example.jp /var/named/example.zone

/var/named/example.zone.signed　←作成された署名済みゾーンファイル

　以上の作業により、以下のようなゾーンファイルが作成されます。

$TTL 86400

@            IN      SOA dns.example.jp. root.example.jp. (

                     2004021401 ; serial

                     3600       ; refresh 1hr

                     900        ; retry 15min

                     604800     ; expire 1w

                     86400      ; min 24hr

)

             IN      NS     dns.example.jp.

dns          IN      A      192.168.10.1

pc1          IN      A      192.168.10.11

pc2          IN      A      192.168.10.12

pc3          IN      A      192.168.10.13

pc4          IN      A      192.168.10.14

pc5          IN      A      192.168.10.15

署名前のゾーンファイル（第2回より）

example.jp.        86400   IN SOA  dns.example.jp. root.example.jp. (

                                   2004021401 ; serial

                                   3600       ; refresh (1 hour)

                                   900        ; retry (15 minutes)

                                   604800     ; expire (1 week)

                                   86400      ; minimum (1 day)

                                   )

                   86400   SIG     SOA 1 2 86400 20040315175332 (

                                   20040214175332 5964 example.jp.

                                   trmSnwDk75DSuqquFEbeEsEu5+sPr3ztL6Qj

                                   （省略）

                                   9gpklPm2fmISWCPtzQ== )

                   86400   NS      dns.example.jp.

                   86400   SIG     NS 1 2 86400 20040315175332 (……（省略）)

                   86400   KEY     256 3 1 (

                                   （省略）

                                   ) ; key id = 32394

                   86400   NXT     dns.example.jp. NS SOA SIG KEY NXT

                   86400   SIG     NXT 1 2 86400 20040315175332 (

                                   20040214175332 5964 example.jp.

                                   （省略）

                                   0E01fOlANPJOrMptoA== )

dns.example.jp.    86400   IN A    192.168.10.1

                   86400   SIG     A 1 3 86400 20040315175332 (……（省略）)

                   86400   NXT     pc1.example.jp. A SIG NXT

                   86400   SIG     NXT 1 3 86400 20040315175332 (……（省略）)

（以下略）

署名後のゾーンファイル

　作成した署名済みゾーンファイル（example.zone.signed）を現在のゾーンファイルに置き換え、

# rndc reload

やnamedの再起動でゾーン情報を更新すれば作業終了です。

注：これだけでは、DNSSEC問い合わせに対応できません。ZSK鍵への署名とDSレコードの登録が必要です。

KEY／SIG／NXTレコード

　DNNSECは仕組みが多少複雑ですが、実際のゾーンファイルの作成は上記のようにdnssec-signzoneコマンドで、ほぼ自動で行えます。署名後のゾーンファイルを見ると、新しい資源レコードが追加されているのが分かります。

KEYレコード：公開鍵を指定

example.jp. KEY 256 3 1 (公開鍵) ; key id = 32394

KEYレコードの例


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レコード：レコードに対する署名を指定

dns.example.jp. SIG A 1 3 86400 20040315175332 (署名)

SIGレコードの例


A：	署名を行ったレコード。例ではdns.example.jp.のAレコードに対して署名が行われている
1：	使用した暗号アルゴリズム。KEYレコードと同様
3：	dns、example、jpのように、オーナーが3ラベルで構成されていることを指定
86400：	TTL
20040315175332：	署名の有効期限。YYYYMMDDHHMMSSフォーマットを使用
(署名)：	Base64でエンコードされた署名

NXTレコード：次に来るレコードを指定

dns.example.jp. NXT pc1.example.jp. A SIG NXT

NXTレコードの例

　上記の例では、dns.example.jpの次にpc1.example.jpのAレコードが来ることが分かります。こうすることで、（dns2やpc0などの）レコード名が存在しないことも保証できます。

　今回使用したゾーンファイルの例では、example.jp→dns.example.jp→pc1→pc2→pc3→pc4→pc5（注）の順で記述されています。

注：ホスト名の後ろのexample.jpを省略しています。

　署名されたゾーンファイルのNXTレコードを見ると、その連鎖順（注）も同じように作られ、最後はpc5→example.jpに戻っています。ドメイン名で連鎖を作り、さらに循環させることで、連鎖の間にはいかなるドメイン名も存在しないことを保証しています。例えば、dns.example.jpの次にpc1.example.jpのAレコードが来るため、dns0.example.jpやdns1.example.jpのようなドメイン名は存在が否定されます。

注：大文字・小文字を区別しないアルファベット順になります。

DNSSEC普及の課題

　BIND 9におけるDS方式への変更など、DNSSECにはまだ発展途上の感があり、普及には時間を要すると思われます。また、下位ゾーンから送られてくる公開鍵を上位ゾーンが確認する際に、いかに出元の保証を行うかなど、まだまだ検討の余地が残されています。何より、現在動いているシステムをどのように新しいものに置き換えるのか。IPv6と同様、大変重要な課題です。

VIEWによるスプリットDNS

前のページへ 1|2|3 次のページへ

SpecialPR