2013年10月から192.jpにDNSSECを実施していますが、KSKやZSKの見直しと更新をしました。ここでは、KSKの更新手順についてまとめたいと思います。
全体の流れ
KSK更新にまつわる全体の流れを図に整理しました。
KSKは上位ゾーン（通常はTLDで、192.jpの場合はjp）にDS情報を登録します。従って、DS情報のTTLに依存して鍵更新の作業を進めていきます。図の1~5の順に1つずつ見ていきます。
- 新しいKSKを作成し、自ゾーンで公開する
- 上位ゾーンへDS情報を登録すると共に、古いDS情報を削除する
- 上位ゾーンへの反映を待つ
- 古いDS情報のキャッシュが切れるのを待つ
- 古いKSKを自ゾーンから削除する
新しいKSKを作成し、自ゾーンで公開する
新しいKSKを作成します。
$ dnssec-keygen -K keys -a RSASHA256 -b 2048 -f ksk -r /dev/urandom -A now -D 20150731235959 192.jp Generating key pair..+.. ..+.+ ...++++++++++..... .......+.....+.......+++..... .++ K192.jp.+008+05332
その後、自ゾーンを署名し、公開します。署名後の更新で情報が書き換わっていることを知らせるため、基となるゾーンファイル（db.192.jp）に記されているSOAレコードのシリアル番号は署名前に更新しておきます。NSEC3オプション（-3）の直後にあるサブシェル（バッククォート）はハッシュに使うsaltで、ランダムな16進数の8字を生成しています。
$ dnssec-signzone -K keys -N keep -o 192.jp -S -3 `head -c 4 /dev/urandom | xxd | cut -b 10-19 | tr -d ' '` db.192.jp
Fetching KSK 48841/RSASHA256 from key repository.
Fetching KSK 5332/RSASHA256 from key repository.
Fetching ZSK 23748/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 2 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
db.192.jp.signed
$ sudo service bind9 reload
* Reloading domain name service... bind9
...done.
上位ゾーンへDS情報を登録すると共に、古いDS情報を削除する
自ゾーンのKSKが上位ゾーンから繋がっていることを示すDS情報は上位ゾーンへ登録します。レジストラにより手続きが異なるので、詳細は省略です。
上位ゾーンへの反映を待つ
レジストラ経由で手続きを行った後、即時反映される場合もありますし、一定時間ごとに反映される場合があります。jpの場合は15分ごとに反映されるため、それ以降に反映されているか確認します。
% dig -t ds 192.jp +nodnssec +norec @a.dns.jp ; <<>> DiG 9.8.1-P1 <<>> -t ds 192.jp +nodnssec +norec @a.dns.jp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62265 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;192.jp. IN DS ;; ANSWER SECTION: 192.jp. 7200 IN DS 5332 8 1 872C681E867B494DCDCCC6136A475B142EFD8CD9 192.jp. 7200 IN DS 5332 8 2 331EDB69BD6E6A2B75FA24D6C7A77C64C72CC8B80B0549B9DBF18BA3 29D357A5 ;; Query time: 8 msec ;; SERVER: 203.119.1.1#53(203.119.1.1) ;; WHEN: Sun Jan 4 08:02:10 2015 ;; MSG SIZE rcvd: 119
古いDS情報のキャッシュが切れるのを待つ
DS情報は上位ゾーンが有する情報のため、TTLは上位ゾーンが指定した値に依存します。jpの場合は7200秒（2時間）のため、DS情報が反映されてから2時間経ってから次の作業を実施します。
古いKSKを自ゾーンから削除する
使わなくなったKSKを削除して再度署名を行います。
$ rm keys/K192.jp.+008+48841.*
% dnssec-signzone -K keys -N keep -o 192.jp -S -3 `head -c 4 /dev/urandom | xxd | cut -b 10-19 | tr -d ' '` -e 20150731235959 db.192.jp
Fetching KSK 5332/RSASHA256 from key repository.
Fetching ZSK 23748/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
db.192.jp.signed
% sudo service bind9 reload
* Reloading domain name service... bind9
...done.
まとめ
ZSKは自ゾーン内で交換を済ませることが出来ますが、KSKを交換するときは自ゾーンのみならず上位ゾーンとのやりとりが発生します。上位ゾーンのTTLも頭に入れて作業を進める必要があることから、最初の図のように時間軸を整理して進めていく必要があると感じました。
Leave a Reply