【STEP3】namedの設定を変更する
署名付きのゾーンファイルが生成できたら、namedの設定を変更し、そのゾーンファイルを読み込ませる。namedの設定ファイルであるnamed.confの下記の部分を変更する。
options { ...(省略)... dnssec-enable yes; ← dnssec-enable を追加 ...(省略)... }; zone "example.jp" { type master; file "zone/example.jp.signed"; ← example.jp.zone から example.jp.signed に変更 };
BIND9.8系ではDNSSECの機能を有効化する「dnssec-enable」は、特に指定しなくても有効であるが、ここでは明示的に有効化している。
named.confの書き換えが完了したら、namedを再起動するか、rndcコマンドを使って設定を再読み込みする。ここではrndcを使って再読み込みを行う。
# rndc reconfig
この時点で、署名付きのゾーンが公開されるため、DNSSECを有効にした要求に対して署名付きの応答を返すようになる。
# dig @localhost example.jp +dnssec +m ;<<>> DiG 9.8.1-P1 <<>> @localhost example.jp +dnssec +m ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36012 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;example.jp. IN A ;; ANSWER SECTION: example.jp. 86400 IN A 192.0.2.80 example.jp. 86400 IN RRSIG A 8 2 86400 20120125140928 ( 20111226140928 32349 example.jp. NAiUM2mMfQv4WwjxbT4IUUDyS2UHr05KQE5hX6sizxHN 9rX3ULgWH268JbxQWRt73s5AGAALb7VXn0P9ColjJbAS ZK9vKkDY4XjtxIhm65G8+hsQiQVUtKrh/8vQSMocV4hu nlKfshXsTF5mKip8lwjdcpzKxXi6c6cTQ67+bFY= ) ...(省略)...
【STEP4】DSレコードの登録依頼を行う
権威DNSサーバ側の用意ができたら、あとは上位ゾーンとの信頼の連鎖を構築するだけである。これは契約しているレジストラ(や指定事業者)に依頼することが多いだろう。
DSレコードは、STEP2で実行した署名コマンド実行後に、/var/named/zoneの下に「dsset-example.jp.」というファイルとして出力されているはずだ。
example.jp. IN DS 20329 8 1 56C289A4C7CADDDFD0EE51681B2467E1DBBC05B8 example.jp. IN DS 20329 8 2 3BE18AEA579673D818231A2F6CCD961F8BA00F4C 76B67B0957662EF5 DC78552D
1行目は、ダイジェストアルゴリズムとしてSHA-1を使って生成されたDSレコードを表している。同様に2行目はSHA-256を使って生成されたDSレコードを表している。信頼の連鎖を構築するためにレジストラ経由でこれらのレコードを登録することになる。
なお、DSレコードは、dnssec-dsfromkeyコマンドを使ってKSK公開鍵ファイルからも生成できる。
# dnssec-dsfromkey Kexample.jp.+008+20329.key example.jp. IN DS 20329 8 1 56C289A4C7CADDDFD0EE51681B2467E1DBBC05B8 example.jp. IN DS 20329 8 2 3BE18AEA579673D818231A2F6CCD961F8BA00F4C 76B67B0957662EF5 DC78552D
レジストラに登録を依頼し、最終的に上位ゾーンにDSレコードが登録されると、上位ゾーンからの信頼の連鎖が構築され、そのゾーンが信頼されたものとなる。
前項の作業で権威DNSサーバの構築が完了し、DNSSECに対応した状態となった。しかし権威DNSサーバではそれ以降も、DNSSECに関連して定期的なメンテナンスが必要となってくる。基本的には下記の3つの作業が定常的に発生することになる。
【1】再署名
署名の有効期間を定期的に再設定するために、再署名を実施する。また、レコード追加などゾーンの内容に変更があった場合も、再署名を行う必要がある。再署名については、署名を行う場合と同様に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
あらかじめ再署名を行う間隔などを決めたら、定期実行する仕組みを使って自動化するとよいだろう。
【2】ZSKの作成・更新
「DNSSECの運用設計」でも触れたが、ZSKやKSKは定期的に作成および更新する必要がある。鍵の作成手順については、初回の鍵生成とほぼ同様であるが、2回目以降の鍵の作成については事前公開の日付、署名に使い始める日付を、鍵の更新サイクルに合わせた形にする必要がある。
例えば、事前公開法によってZSKを運用し、初回のZSK生成から3週間後の時点で新しいZSKを事前公開するとしよう。その場合は下記のようなコマンドで新しいZSKを作成できる。
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111222000000 -A 20120101000000 -I 20120131235959 example.jp
作成したZSKは3週間後の2011年12月20日0時0分0秒から事前公開され、2012年1月1日0時0分0秒から署名に使われることを表している。
図3は初回の鍵と2回目の鍵の関係を表したものである。ただしこれらは再署名の時点で反映されるため、2011年12月20日0時0分0秒以降と2012年1月1日0時0分0秒以降に、再署名およびゾーン情報の再読み込みを行うとよいだろう。
【3】KSKの作成・更新
ZSKと同様に、KSKも定期的に作成・更新しなければならない。こちらも作成作業自体は、基本的にはZSKの2回目の作成と同様だ。
ただし、KSKは対応するDSレコードを上位ゾーンに登録しているため、KSKの更新とともにDSレコードの更新申請が必要となる。二重署名法を使ってKSKを運用する場合、DSレコードの再申請は、二重署名がされている期間中にする必要がある。
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20121201000000 -A 20121201000000 -I 201312310000 example.jp
キーロールオーバー中には複数のZSKやKSKが存在するため、鍵を取り違えることのないよう、鍵タグを用いてきちんと区別するなどの注意が必要である。
以上、権威DNSサーバにおけるDNSSECの対応について駆け足で紹介してきたが、実際には期間や期限などを明確に定めて運用していく必要がある。
現時点では、権威DNSサーバにおけるDNSSEC運用はまだ簡単なものとはいいがたいが、今後、運用を補助するツールや枠組みがさらに整備されていくと期待できる。また、DNSSECが有用なものとなるためには、権威DNSサーバだけでなくキャッシュDNSサーバの対応も並行して進んでいかなければならない。
次回は、DNSSECをめぐる現況について紹介する。
日本レジストリサービス(JPRS)技術陣がDNSの「本質」を踏まえた解説本を出しました。DNSの仕組みや動作について基本から解説するほか、最新の情報に基づいた設定、運用方法を紹介しています。
実践DNS DNSSEC時代のDNSの設定と運用
株式会社日本レジストリサービス(JPRS)監修 民田雅人、森下泰宏、坂口智哉著
アスキー・メディアワークス
2011年5月 ISBN:978-4-04-870073-3 定価:2940円(本体2800円)
Copyright © ITmedia, Inc. All Rights Reserved.