特に書くこともないけど、

引用:auto-dnssec maintain; を試してみる

ま、取り敢えず、これで上位へのDSやDLVの登録なんかを除けば、鍵を作り足し忘れない限り、大丈夫そうな状態が作れる感じ。適切なoffset値でdnssec-keygen(8)にtiming optionを指定してcron(8)あたりで呼べば、作成もなんとかなるのかも。

取り敢えず、こんな感じのcrontab(5)をnamed(8)の実行ユーザーで作って試してみる。GNU dateが使える環境前提ですけど。

SHELL=/bin/sh
MAILTO=""
#
13 * * * * /usr/sbin/dnssec-keygen -r /dev/urandom -3 -a RSASHA256 \
 -b 1024 -i 1h \
 -A `/bin/date -u -d "1 hour" "+\%Y\%m\%d\%H\%M\%S"` \ 
 -I `/bin/date -u -d "2 hours 10 minutes" "+\%Y\%m\%d\%H\%M\%S"` \ 
 -D `/bin/date -u -d "2 hours 20 minutes" "+\%Y\%m\%d\%H\%M\%S"` \ 
 -K /var/named/chroot/var/named/keys/example.jp \
 -n ZONE example.jp > /dev/null 2>&1 \
 && /usr/sbin/rndc loadkeys example.jp. > /dev/null 2>&1

問題なさそうなら、-iの値を1moぐらいにして、hourをmonthにして、10 mintutesを3 daysぐらいにして実機でやってみようかな。

dnssec-keygen(8)ってman読むと、-Pも-Aもdefault is "now"って書いてますけど、-Aだけ書いて-P付けなかったら-Pには-Aの値が採用されるんですね。おもいっきり-iの説明に書いてますけど見落としてた。

所有ドメインを使って、auto-dnssec maintain;な設定で、暫くISC DLVして遊んでみているわけなんですが…。

引用:auto-dnssec maintain; を試してみる

これで、Kexample.jp.+008+12199とKexample.jp.+008+59595が署名に使用され、Wed Oct 27 22:45:55 JST 2010 を過ぎればKexample.jp.+008+58539がゾーンに公開され、Thu Oct 28 00:42:57 JST 2010を過ぎればKexample.jp.+008+59595が署名に使われなくなったりしてくれます。

PublishとDeleteに関して言及を避けているわけですが、まあ、単刀直入にいえばPublishとDeleteのお時間には勝手には何も起きなかったわけでして、まあ、そのあたりどうなのかなと暫く使ってみてまして…。

レコードの追加・削除・変更等のきっかけがあれば、そのときのkey-directory等で指定されたディレクトリにある鍵に応じてPublishもDeleteもActivateもInactiveも行ってくれるんですが、結論から言いますと、auto-dnssec maintain;の設定の下で、

# rndc loadkeys zone [class [view]]

を実行してやると、その時点でkey-directoryに指定されたディレクトリにある鍵に応じた処理を時の経過と共に行ってくれるようです。"ようです"というのが微妙な表現ですが、例えば、Activateに関していえば、Activateに指定されている時間に署名をしてくれたりしてくれなかったりでなんだか微妙な感じです。ログに

next key event: 08-Nov-2010 23:10:48.521

という感じで、次に起こる鍵の追加や削除や署名に関することが起こる日時が示されるのですが、key-directory等で指定されたディレクトリにある鍵のPublishとActivateとInactiveとDeleteに指定されている時間を時系列に並べて調べてみると、なぜだか、たまに飛ばされてしまうものがあるようです。傾向としてはActivateな時間とInactiveな時間にあって、PublishとDeleteな時間にはないようです。というか今のところPublishとDeleteな時間には体験してないです。大雑把にいえば、Activateな時間に署名が自動的に付くこともあれば付かないこともある、Inactiveな時間を過ぎた時間にDelete等のSOA RRのシリアルが変更されるようなイベントが入ってもInactiveな鍵で署名され続けたりすることがあります。何度か、同じ時間差条件でテストしてみましたけど、取り敢えず、傾向は読めないです。バグなんですかね？

まあ、そんな感じなので、新しい鍵がActivateなお時間に特に署名されることがないまま古い鍵がDeleteされる時間が訪れ、そのタイミングで新しい鍵がActivateになったりとTTL的に微妙な状態が起こったりするときもあります。

後、

# rndc sign zone [class [view]]

という、そのときのkey-directory等に指定されたディレクトリにある鍵を読み込んでActivateな時間を過ぎている鍵で署名してくれるコマンドもあるのですが、これもたまに微妙な動作します。既に Inactiveな鍵で署名を付けたりしてくれることがありました。「あれ？」と思って、短い有効期間の鍵でテストしているので、その時間の短さが影響しているのかもしれませんけど、loadkeysを含めて、今のところ手放しにおまかせするのは少々躊躇われるところかもしれません。何か使い方を間違えているのかもしれませんけど。

BIND-9.7.2-P2でauto-dnssec maintain;を試したメモ。

ARMを見る限り、auto-dnssecに指定できる値としては、allow|maintain|create|offがあるみたいですけど、allowは、dnssec-signzone(8)の-Sで使えるSmart signingに毛が生えた程度な感じだし、完全放置プレイができそうなcreateは、まだ未実装みたいなので、取り敢えず、一番便利そうなmaintainを試してみることに。大雑把にいえば、timing metadataを付けた鍵を用意しておけば、そのtimingで鍵をゾーンにpublishedにしたり、ゾーンでactiveにしたりInactiveにしたりrevokeにしたり、ゾーンからdeleteしたりしてくれるシロモノのようです。

お試しの環境はCentOS 5.5で、ディレクトリ構成なんかはchrootな場合のデフォルトです。起動オプションは、

# /usr/sbin/named -u named -t /var/named/chroot

になります。用意するゾーンはテストなのでexample.jp.にして、鍵は、/var/named/chroot/var/named/keys/example.jpに置くことにして、ゾーンファイルは、/var/named/chroot/var/named/dynamicに置くことにします。まず、下準備。

$ su -
# cd /var/run/named
# ln -s /var/named/chroot/var/run/named/session.key .
# cd /var/named/chroot/var/named
# mkdir -m 770 dynamic
# chown -R named:named dynamic
# mkdir -m 770 keys
# chown -R named:named keys
# su - named --shell=/bin/bash
$ cd /var/named/chroot/var/named/keys
$ mkdir -m 770 example.jp
$ cd example.jp

んで、鍵を作ります。お試しするだけなので、賞味期限は短めで。まずは、KSK。

今すぐゾーンに公開され署名に使用され、1 日後署名に使用されなくなり、2 日後ゾーンから消えるものを。

$ /usr/sbin/dnssec-keygen -f KSK -r /dev/urandom -3 -a RSASHA256 \
 -b 2048 -I +86400 -D +172800 -n ZONE example.jp
Generating key pair........+++ .........................................................+++
Kexample.jp.+008+12199
$ cat Kexample.jp.+008+12199.key
; This is a key-signing key, keyid 12199, for example.jp.
; Created: 20101027123754 (Wed Oct 27 21:37:54 2010)
; Publish: 20101027123754 (Wed Oct 27 21:37:54 2010)
; Activate: 20101027123754 (Wed Oct 27 21:37:54 2010)
; Inactive: 20101028123754 (Thu Oct 28 21:37:54 2010)
; Delete: 20101029123754 (Fri Oct 29 21:37:54 2010)
example.jp. IN DNSKEY 257 3 8 ...
$

次に、ZSK。2つ作ります。

今すぐゾーンに公開され署名に使用され、3 時間後署名に使用されなくなり、4 時間後ゾーンから消えるものと、1 時間後ゾーンに公開され、2 時間後署名に使用され、5 時間後署名に使用されなくなり、6 時間後ゾーンから消えるものを。

$ /usr/sbin/dnssec-keygen -r /dev/urandom -3 -a RSASHA256 \
 -b 1024 -I +10800 -D +14400 -n ZONE example.jp
Generating key pair...++++++ ..............++++++
Kexample.jp.+008+59595
$ cat Kexample.jp.+008+59595.key
; This is a zone-signing key, keyid 59595, for example.jp.
; Created: 20101027124257 (Wed Oct 27 21:42:57 2010)
; Publish: 20101027124257 (Wed Oct 27 21:42:57 2010)
; Activate: 20101027124257 (Wed Oct 27 21:42:57 2010)
; Inactive: 20101027154257 (Thu Oct 28 00:42:57 2010)
; Delete: 20101027164257 (Thu Oct 28 01:42:57 2010)
example.jp. IN DNSKEY 256 3 8 ...
$ /usr/sbin/dnssec-keygen -r /dev/urandom -3 -a RSASHA256 \
 -b 1024 -P +3600 -A +7200 -I +18000 -D +21600 -n ZONE example.jp
Generating key pair..........++++++ ..............++++++
Kexample.jp.+008+58539
$ cat Kexample.jp.+008+58539.key
; This is a zone-signing key, keyid 58539, for example.jp.
; Created: 20101027124555 (Wed Oct 27 21:45:55 2010)
; Publish: 20101027134555 (Wed Oct 27 22:45:55 2010)
; Activate: 20101027144555 (Wed Oct 27 23:45:55 2010)
; Inactive: 20101027174555 (Thu Oct 28 02:45:55 2010)
; Delete: 20101027184555 (Thu Oct 28 03:45:55 2010)
example.jp. IN DNSKEY 256 3 8 ...
$

ちなみに、metadataの20101027124555みたいな日時はUTCなもの、Wed Oct 27 21:45:55 2010みたいなのはJSTです。そして、テスト用に簡単なexample.jp.ゾーンファイルを作成。

$ cd ../../dynamic
$ cat > example.jp.zone.signed
$ORIGIN example.jp.
$TTL 3600
@       IN      SOA     localhost.example.jp.  hostmaster.example.jp.    (
                                2010102701      ; Serial
                                10800           ; Refresh
                                1200            ; Retry
                                604800          ; Expire
                                1200    )       ; Minimum TTL

                        IN      NS      localhost.example.jp.
                0       IN      NSEC3PARAM 1 0 10 1234ab
localhost               IN      A       127.0.0.1
$

まあ、かなり適当です。

次に、named.conf(5)のoptionsかviewに

dnssec-enable yes;

を足して、zoneを以下のように追加します。

zone "example.jp." {
	type master;
	file "dynamic/example.jp.zone.signed";
	key-directory "/var/named/keys/example.jp";
	update-policy local;
	auto-dnssec maintain;
};

尚、お試しならばzoneにdnssec-secure-to-insecure yes;を足しておいた方が幸せかもしれません。ちなみに、update-policy local;ですが、名前からするとDynamic DNSなupdateをローカルに限定してくれそうですが、ARMによると、

update-policy { grant local-ddns zonesub any; };

と完全に等価ですので、例えば、

view "world" {
        match-clients { any; };
        match-destinations { 外側のインターフェースのIPアドレス; };
        ...
};

みたいなviewに追加した場合、デフォルトのTSIG session keyを他のホストにコピーすればリモートからもupdateがかけられます。尚、デフォルトのTSIG session keyの場所や名前も変えられるようで、optionsに

session-keyfile "/var/run/named/session.key";
session-keyname "local-ddns";
session-keyalg "hmac-sha256";

とか記述すればできます。ちなみに、上記はデフォルト値です。

これで、準備ができたので、reloadしてloadkeysします^(*1)。

# rndc reload
# rndc loadkeys example.jp.

これで、Kexample.jp.+008+12199とKexample.jp.+008+59595が署名に使用され、Wed Oct 27 22:45:55 JST 2010 を過ぎればKexample.jp.+008+58539がゾーンに公開され、Thu Oct 28 00:42:57 JST 2010を過ぎればKexample.jp.+008+59595が署名に使われなくなったりしてくれます^(*2)。

ゾーンへの RR の追加などは、nsupdate(1)で行います。ローカルから更新できるview内にあるのであれば、

# nsupdate -l

なんぞで、そうでなければ、

# nsupdate -k /var/run/named/session.key

とかして、serverを指定するなりすれば更新できます。別解としては、

# rndc freeze example.jp.

して、/var/named/chroot/var/named/dynamic/example.jp.zone.signedをエディタで編集し、SOA RRのシリアルを上げて、

# rndc thaw example.jp.

する手もあります。ちなみに、鍵に timing metadata が付いていて、ちゃんとkey-directoryが指定されていれば、auto-dnssec off;でもnsupdate(1)等で更新すれば適切に署名してくれます。

ただ、key-directoryを指定せずデフォルト以外の場所に鍵を置いていたりすると、署名の有効期限が近づいたときに、named(8)が勝手に署名の更新をかけようとして鍵が見つからないので、署名の除去をしたりするのはなんだかなといった感じ。DNSSECなゾーンはDynamic DNSが使えるように設定しとかないと面倒な状態になるみたいですね。auto-dnssec off;なら署名の期限切れなんて自己責任にしてくれてもいいんじゃないかなと。設定であるのかな。取り敢えず、rndc freezeしとけば、そういう更新は起こりませんけど、なんか使い方が違う気がしますし。

ま、取り敢えず、これで上位へのDSやDLVの登録なんかを除けば、鍵を作り足し忘れない限り、大丈夫そうな状態が作れる感じ。適切なoffset値でdnssec-keygen(8)にtiming optionを指定してcron(8)あたりで呼べば、作成もなんとかなるのかも。

---

*1: rndc loadkeysに関する記述を追加(Nov 09, 2010)。まあ、reloadしてるんで問題ないんですけど、鍵追加したときにはloadkeysしようねという意味で。
*2: うまく動作しない場合もあるみたいです(Nov 09, 2010)。

RTX1200とRTX1100とRTX1000ぐらいしか試してませんけど、こいつらににDO bit立てた名前解決をお願いすると必要な応答すら返さないのはうちだけですかね。ファームが古い？

.jp DNSSECキーセレモニーの実施について

10月17日(日)の予定みたいですけど、今のところルートゾーンにjp.のDS RRは見当たらず。もうちーとかかるんですかね。後は、今後のプロバイダ側のセカンダリなんぞの対応が気になるところ。そのあたりはやっぱり2011年1月16日以降なんかな。

緊急メンテナンスとなりましたか

11日のメンテが終了して改善…といいますか使い物にならないレベルからなんとか我慢して使えるレベルにはなったという感じでしょうか。たぶん、根の深い問題なのでしょうかね。

VPSのディスクのベンチマークって意味があるのかどうかわからないですけど、bonnie++なんぞで計る限り、1000円未満で借りることができる他社の方がだいぶ速い感じ。ということは今のウリは回線の安定性とかディスクの容量とかでしょうかね。ちょっと価格差考えると悲しいところ。まあ、頑張ってください、中の方々。

WebARENA SuitePRO V3 をしばし使ってみて

7日に設備増強の緊急メンテナンスやったけど、その結果、一部仮想サーバーで著しいパフォーマンス低下を招いて、11日に緊急メンテナンスになってしまった。しっかり、一部に該当してしまってるし。

なんか、空のディレクトリで ls とかやっても30秒ぐらい応答が戻ってこなかったり、ファイル開こうとするとそのぐらい待たされたりで、結構厳しい状況。

でも、この状況だと、担当者か機器の納品業者かわかりませんけど、大変な状況なんだろうなぁ。

WebARENA PRO V3

V2 から乗り換えて2ヶ月ほど経過しましたけど、ディスク I/O が極端に遅いときが多々あるのは私んとこだけですかね？

『吟道光世流志清吟社 第八回吟道祭大阪』のご案内。

とき: 2010年11月23日(火・祝) 午前9時30分開演
ところ: 大阪国際交流センター「大ホール」
〒543-0001 大阪市天王寺区上本町8-2-6

入場は無料だそうです。

RPMforgeから取れるthttpd-2.25b-4.el5.rf.x86_64.rpmですけど、indexing出来ないようにしてあるんですね。

うーん、デフォがindexingアリなんだから、別にそんな変更加えなくてもいいような。リコンパイルせんと変更できないし。ちなみに、specファイルのdescription見ればわかりますが、thttpd-2.25b-4.rf.svn3053.src.rpm取り寄せて、インストールして、

# rpmbuild -bb thttpd.spec --with indexes

とかすれば、indexingできるrpmが出来ます。