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

BIND9.8.0rc1でDNS64を使ってみる

*生保単独* — Sat, 19 Feb 2011 15:30:04 +0900

BIND-9.8.0rc1でdns64を試したメモ。

IPv6のみのホストがIPv4のホストにアクセスする場合に、IPv6セグメントとIPv4セグメントの間にNAT64サーバーという変換機能付ゲートウェイを設置してアクセスを可能にする仕組みがあるようですが、その際、DNSがIPv4ホストのAを返してもIPv6セグメントでは海を車で渡れと言われているようなもので使えないので、エンドポイントとなるNAT64サーバーのインターフェースへの繋ぎとなるAAAAをある規則に従って合成して返すのがDNS64の役割みたいです。

named.confに記載するdns64ディレクティブは、そのAから合成変換したAAAAを作る作り方みたいなものを定義するもので、optionsとviewに書けるみたいです。具体的には、

acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
...
dns64 64:FF9B::/96 {
    clients {
        2001:BD8:0:1::/64;
    };
    mapped { !rfc1918; any; };
    exclude { 64:FF9B::/96; ::ffff:0000:0000/96; };
    suffix ::;
    recursive-only yes;
    break-dnssec yes;
};
dns64-server "dns64.example.jp.";
dns64-contact "hostmaster.example.jp.";

のように書くようです。合成変換するフォーマットについての詳細はRFC6052を参照することになりますが、dns64の後の64:FF9B::/96のところにIPv6-prefixを定義します。これは合成変換後のAAAAのプレフィックスになります。残りのものについては以下に列挙します。

clients…合成変換したAAAAを返す対象となるクライアントを定義します。デフォルトはany;です。
mapped…合成変換の対象となるA RRの値を定義します。デフォルトはany;です。
exclude…合成変換が適用されたアドレスかどうかの判定から除外するアドレスを記載します。
suffix…RFC6052の2.2.IPv4-Embedded IPv6 Address Formatに記載されているprefixが96以外のときにsuffixにはめ込む値を定義します。例えば、prefixが64:FF9B::/40でsuffixが::1f2aで変換対象のAが192.0.2.2だとすると、変換後のAAAAは64:ff9b:c0:2:2::1f2aになります。
recursive-only…RDビットが起っている問い合わせのみに変換後のAAAAを返すかどうかを定義します。つまりyesにすると再帰クエリーの場合に変換後のAAAAを返します。
break-dnssec…DNSSECの問い合わせに対してAAAAを返すかどうかを定義します。noにするとAにDNSSECの署名がある場合にDOビットをセットした問い合わせを行うと変換後のAAAAを返しません。yesにすると変換対象とします。当然ですが変換後のAAAAに署名は付きません。といいますか付けることができません。
dns64-server…prefixに対するIP6.ARPA.のマスターサーバーの値を定義します。例えば、prefixが64:FF9B::/32の場合にb.9.f.f.4.6.0.0.ip6.arpa.のSOAを問い合わせると、マスターサーバーのところにここに定義した値が入ります。
dns64-contact…prefixに対するIP6.ARPA.の管理者メールアドレスの値を定義します。dns64-serverの例と合わせて具体的なSOAの値を記載すると以下のようになります。
b.9.f.f.4.6.0.0.ip6.arpa. 86400 IN SOA dns64.example.jp. hostmaster.example.jp. 0 28800 7200 604800 86400

ちなみに、dns64は複数記載してクライアント毎にprefixを変えたりできるようです。

上記具体例の設定で

host.example.jp. 86400 IN A 192.0.2.2

のAAAAを問い合わせると

host.example.jp. 10800 IN AAAA 64:ff9b::c000:202

となるようです。変換後のTTLはネガティブキャッシュのものとなるようです。

ISC DLVからDS方式の移行

*生保単独* — Wed, 19 Jan 2011 19:14:08 +0900

JPRSがJPドメイン名サービスにDNSSECを導入したことに伴いISC DLVからJPRS上のDS方式に移行したので、そのメモでもと。尚、他の関連ネタ同様、ここなんかに書いているauto-dnssec maintain;が前提になっています。auto-dnssec maintain;についてはBIND97付属のARMの他、これなんかも参考になりそうです。

まず、新しいKSKを作ります。ISC DLVで使っていたものをそのまま移行でもよいのでしょうけど、折角だしこの機会に切り替えた方がよいかと思いまして。使用期間もわかりやすいかと思いますし。まあ、ゴタクは兎も角、新しいKSK作ります。

$ su -
# su - named --shell=/bin/bash
$ /usr/sbin/dnssec-keygen -f KSK -r /dev/urandom -3 -a \
 RSASHA256 -b 2048 -P now -A now+30h -I now+13mo -D now+13mo \
 -K /var/named/chroot/var/named/keys/example.jp \
 -n ZONE example.jp
Generating key pair...
Kexample.jp.+008+02746

KSKのロールオーバー方式ですが、こことかここに2重署名方式(Double Signature)とありますので、それに準じてみたいと思います。とはいうものの、そもそも登録しているところが違うので意味合いが変わって来ている感はありますが、まあ、似たような感じでやったと思って頂ければ。まず、publishedになってからactiveにするまでの時間ですが、DNSKEYのTTLとゾーン転送にかかる時間と誤差程度の作業時間(例えば、鍵作ってから実際に公開するまでの時間とか)ぐらいみればいいわけですが、TTLはまあ一般的には1日ぐらいだと思いますし、ゾーン転送は最近はNOTIFYとかあるのでそんなに掛からないとは思えども、普通に転送する場合とか失敗する場合とかも考えて多めに見積もって6時間ぐらいみておけばいいかなということで30時間としています。retiredとdeletedはどうせ更新時に明示的に行うことなので、ちょっと長めに適当です。

で、これで、鍵が出来ているはずなので、

$ rndc loadkeys example.jp.

とします。で、作成したKexample.jp.+008+02746でDNSKEYの署名が開始されるまで待ちます。要するに30時間後です。署名が開始されたらDSを申請します。dnssec-dsfromkey(8)を使ってDS RRを得ます。

$ /usr/sbin/dnssec-dsfromkey \
 /var/named/chroot/var/named/keys/example.jp/Kexample.jp.+008+02746.key
example.jp. IN DS 2746 8 1 1D8F72D56BEA0EABA6E6BCAC2093906135C9457B
example.jp. IN DS 2746 8 2 C6884BFF053E0F63B00153411AD3873DCD9462CBDD1261707CA83F2B 762319F7

レジストラにもよるのでしょうけど、利用中の名づけてねっとでは鍵ID以降、つまり、

2746 8 1 1D8F72D56BEA0EABA6E6BCAC2093906135C9457B
2746 8 2 C6884BFF053E0F63B00153411AD3873DCD9462CBDD1261707CA83F2B 762319F7

をフォームに貼り付ける方式でした。まあ、このあたりは利用中のレジストラのやり方に従えばよいだけかと思います。

親のゾーン(この場合はjp)にDS RRが登録されるのを待ちます。jp.のNS RRは、

$ dig jp. ns

なんぞで得られると思いますし、それらに

$ dig +norec @a.dns.jp example.jp. ds

等とすれば確認はできるかと思います。確認できたら、ISC DLVからDLV RRを消します。Zone Actionsの(delete)をぽちっとするだけです。ここで、また、DLV RRのTTLとゾーン転送にかかる時間程度を待つことになりますが、TTLが3600、Refreshが7200のようなので、3, 4時間程度待てばよいでしょう。その後、古いKSKがKexample.jp.+008+12199だったとしますと、dnssec-settime(8)使って、

$ /usr/sbin/dnssec-settime -I now \
 /var/named/chroot/var/named/keys/example.jp/Kexample.jp.+008+12199
$ rndc loadkeys example.jp.

とします。その後、

$ /usr/sbin/dnssec-settime -D now \
 /var/named/chroot/var/named/keys/example.jp/Kexample.jp.+008+12199
$ rndc loadkeys example.jp.

とすればゾーンから古いKSKは消えてくれます。^(*1)。

*1: 別に-Iと-Dを一気にやってしまってもいいのですが、なんとなくかわいそうな気がするものでw

NSEC3PARAMをCRON(8)で更新する(DNSSECネタ)

*生保単独* — Sun, 16 Jan 2011 03:28:13 +0900

ネタ的には「auto-dnssec maintain; を試してみる」あたりの設定が前提です。

まず、以下のようなスクリプトを作ります。なるべく通常インストールされてそうなコマンドに限定して書いたつもり。

$ su -
# cd /var/named
# mkdir bin
# chown -R named:named bin
# su - named --shell=/bin/bash
$ cd bin
$ cat > update-nsec3param.sh
#!/bin/sh

RETVAL=0

usage () {
    echo $"Usage: $0 -s server_ip_address -d zone_name" 1>&2
    RETVAL=1
}

OPT=""
DOMAIN=""
SERVER=""
while getopts s:d: OPT
do
    case $OPT in
        d) DOMAIN=$OPTARG
           ;;
        s) SERVER=$OPTARG
           ;;
        \?) usage
            exit $RETVAL
            ;;
    esac
done
shift `expr $OPTIND - 1`

if [ -z "$DOMAIN" ]; then
    usage
    exit $RETVAL
fi

if [ -z "$SERVER" ]; then
    usage
    exit $RETVAL
fi

ITER=$((RANDOM % 6 + 5))
LEN=$((RANDOM % 16 + 3))
HASH=`/usr/bin/openssl rand $LEN | /usr/bin/hexdump -e '1/1 "%02x"'`


cat << UFILE
server $SERVER
update delete $DOMAIN. IN NSEC3PARAM
update add $DOMAIN. 0 IN NSEC3PARAM 1 0 $ITER $HASH
send
UFILE

exit 0

スクリプトはopenssl(1)とhexdump(1)がインストールされていることを前提にしてます。saltの長さやiterationsの回数は適当です。まあ、長すぎず短すぎない程度にした感じ。

nsupdate(1)を受け付けてくれるIPアドレスを192.0.2.2、更新対象のゾーンをexample.jpと仮にでもしておきます。crontab -eとかして以下のような行を追加します。

10 3 1,11,21 * * /var/named/bin/update-nsec3param.sh \
 -s 192.0.2.2 -d example.jp \
 | /usr/bin/nsupdate \
 -k /var/named/chroot/var/run/named/session.key \
 > /dev/null 2>&1

言うまでもないですが\は継続行の意味です。これで毎月1日11日21日の3時10分頃にNSEC3PARAMを更新してくれるはず。

多数派は言わざるですので

*生保単独* — Mon, 03 Jan 2011 17:51:22 +0900

引用:窒息死亡事故が多発する餅はなぜ規制されないのか？

危ないと言われれば、コストがかかり多少利便性が悪くなっても、危なくないように対応するのが日本の行政だ。彼らは国民の声を聞いて仕事をしているのだ（と少なくとも彼らは主張するだろう）。

責任の一端は彼らにそういう仕事をさせてきた我々社会の側にもある。無視できるほどのリスクに目くじらを立て、責任者は誰だ？と犯人探しをし、多額の損害賠償と再発防止策を求める。そのたびに新たな規制が追加され、少しずつ社会は住みにくくなる。もちろんそうした規制の中には必要なものも多い。しかし不要なものも多いのもまた事実だ。

この負の連鎖をなんとか断ち切り、より全体的な視点でバランスのとれた対応をすることは出来ないのか、それこそ政治主導の出番なのだろうけれど……ねえ？

恐らく、無視できるほどのリスクに関しては、犯人探しをしたり多額の損害賠償を求めたり再発防止策を求めている方々は少数なはずで、それらを不要と思っている人は多数なはずだと思うのですが、そもそも不要と思っている人は目くじらを立てない、つまり、意見を出さないですから。

何も言わない人と何か言ってくる人のどちらに対応するかといえば、通常、何か言ってくる人に対応せざるを得ないでしょうし。「危ないと＊言われれば＊」もそうなのでしょう。

そういう多数派が積極的に意見を出さないという意味で「責任の一端は彼らにそういう仕事をさせてきた我々社会の側にもある」というのは的を射ているとは思いますけど、例えば、モンペにその他の親御さんが「おまえの教育は間違っている」と思っても面と向かって主張しないのと同じで、ある意味三猿的なものが今の日本の文化的なところに根付いてますから。

結局のところ、より全体的な視点でバランスのとれた対応をするためには、そういう物言わぬ少数派が積極的に意見を言う社会を作るか、行政が積極的に意見を取りに行くかしかないんでしょうけど、それをどう実現するかが難しいところですかね。

謹賀新年

*生保単独* — Sat, 01 Jan 2011 00:36:08 +0900

新年あけましておめでとう御座います。

なんだかな…ServersMan@VPS

*生保単独* — Thu, 30 Dec 2010 10:38:18 +0900

今朝、ServersMan@VPSのメンテに関してメールが。

引用:ServersMan@VPS メンテナンス経緯のご報告ならびに AirDisplay設定変更のお願い

# 当メールは、SSH のポート番号変更にあたりまして、再度手動による設定が
# 必要なお客様を対象にお送りさせていただいております。
# 大変ご面倒ながら、ご協力をお願いいたします。

勝手に環境弄っておいてその修正は客の方で行えと？まあ、各所で勝手に弄るなと突っ込まれた手前、弄れない立場になってしまったんでしょうかね。個人的には、どのみち使ってないし使わない機能なのでどうでもいいんですが。そもそも、

引用:ServersMan@VPSサービス SSH接続用のポート変更に伴う設定変更のお願い

プリインストールされているアプリケーションの他、お客様が自由に環境を構築できるメリットもありますが、その反面、セキュリティ対策もお客様ご自身で行っていただく必要があります。

と言っておきながら、その対策を客に任せていないからこういうことになるんじゃないかと思ったり。まあ、途中から高負荷対策などという名目が案内メールに入り込んできてますので、DTI都合の意味合いが大きいメンテなんだと邪推したりしてますが。

別にたいした料金払っているわけではないので、弄りたきゃ弄ってもらえればいいとは思うのですが^(*1)、なんかセキュリティ対策を口実に負荷対策を行うのはなんだかなといったところ。言っていることが首尾一貫してないし、言い訳がましい口実を書いているように読めてしまうところが個人的に反感を買う要因ではないかと思うところ。

*1: 事前に断る必要はあると思いますけど。

続・YAMAHAルータDNSリカーシブサーバー機能検証(フルリゾルバがBIND 9.7.2-P3の場合)

*生保単独* — Thu, 30 Dec 2010 06:08:37 +0900

YAMAHAルータDNSリカーシブサーバー機能検証

同じテストをフルリゾルバをBIND 9.7.2-P3にしてやってみた。

まず、dhcp scope optionを付けない場合。要するに、

DNS Servers . . . . . . . . . . . : 192.168.141.1
                                    192.0.2.81

となる場合。結果は、

42/43 tests passed(failedしたのはEのみ)。かなり良好です。

次に、dhcp scope option 1 dns=192.168.141.1とした場合。要するに、

DNS Servers . . . . . . . . . . . : 192.168.141.1

となる場合。ルータのみに問い合わせる場合です。結果は、

6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)。変わらず悲惨です。

次に、dhcp scope option 1 dns=192.0.2.81とした場合。要するに、

DNS Servers . . . . . . . . . . . : 192.0.2.81

となる場合で、直接フルリゾルバに問い合わせる場合です。結果は、

43/43 tests passed。この上ないですな。Unboundの場合はバージョンが古いからか設定に不足があるのかもですね。いずれにしろ、RTX1100のDNSリカーシブサーバー機能は駄目っぽい。

YAMAHAルータDNSリカーシブサーバー機能検証

*生保単独* — Thu, 30 Dec 2010 02:15:07 +0900

RTX1100のDNSリカーシブサーバー機能ですがDNSSECが絡むとあまりよろしくない感じがするので検証してみようかと。検証といってもhttp://www.nic.cz/dnssectests/あたりからダウンロードしたDNSSEC Hardware Tester(Windows version)によるものなのでおもいっきり他力本願ではありますが。

まあ、枯れた機種かもしれませんけど、一応現役で売ってますし、ファームウェアも2010年12月30日現在最新のRev.8.03.90にして検証してみました。

RTX1100のプライベート側のIPアドレスは192.168.141.1、DNSサーバーのIPアドレスは実際のものを書くのも何なので192.0.2.81としておきます。192.0.2.81で動作しているフルリゾルバはFedora EPELのunbound 1.4.4です。この場合、要所だけ書くと、

…
ip lan1 address 192.168.141.1/24
…
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.141.192-192.168.141.224/24 expire 1:00
dns service recursive
dns server 192.0.2.81
…

みたいな設定を入れるかと思うんですが、この設定でWindowsクライアントなんぞでipconfig /allなんぞを実行すると、以下のような感じで、

IP Address. . . . . . . . . . . . : 192.168.141.192
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.141.1
DHCP Server . . . . . . . . . . . : 192.168.141.1
DNS Servers . . . . . . . . . . . : 192.168.141.1
                                    192.0.2.81
Lease Obtained. . . . . . . . . . : 2010年12月30日 0:42:09
Lease Expires . . . . . . . . . . : 2010年12月30日 1:42:09

DNS Servers欄にDNSリカーシブサーバー機能が動作しているRTX1100のIPアドレスと実際のDNSサーバーのIPアドレスが返ってきます。実際、この場合はそこそこ良好な結果(38/43 tests passedでfailedはC.1, C.2, D.1, D.2, Eのみ)を叩き出すのですが、なんとなく192.0.2.81に直接問い合わせた結果がよいだけで本来のDNSリカーシブサーバー機能は頑張ってないんじゃないのかと思えたので検証してみる次第。

そのようなわけで、DHCPがDNSサーバーとして192.168.141.1しか返さないように、以下の設定を加えます。

dhcp scope option 1 dns=192.168.141.1

これで、ipconfig /allなんぞを実行すると、

IP Address. . . . . . . . . . . . : 192.168.141.192
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.141.1
DHCP Server . . . . . . . . . . . : 192.168.141.1
DNS Servers . . . . . . . . . . . : 192.168.141.1
Lease Obtained. . . . . . . . . . : 2010年12月30日 0:52:36
Lease Expires . . . . . . . . . . : 2010年12月30日 1:52:36

となります。これでテストしてみると、

6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)のみ。結構悲惨な有様。

そもそもルータにDNSリカーシブサーバー機能が要るのかどうかは兎も角、RTX1100のDNSリカーシブサーバー機能は使えない感じ。何か設定が足らんのでしょうか。最新の機種だとそうでもないんですかね。

ちなみに、実際のルータの全設定は以下のような感じです。なるべく余計なものは書かないようにしたつもり。

dhcp scope option付

console character ascii
ip route default gateway pp 1
ip filter source-route on
ip filter directed-broadcast on
ip icmp redirect send off
ip lan1 address 192.168.141.1/24
pp select 1
 pp always-on on
 pppoe use lan2
 pp auth accept chap
 pp auth myname user_id password
 ppp lcp mru on 1438
 ppp ipcp ipaddress on
 ppp ipcp msext on
 ppp ccp type none
 ip pp mtu 1438
 ip pp nat descriptor 1
 pp enable 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 ipcp
nat descriptor address inner 1 auto
rip use off
telnetd service on
telnetd host 192.168.141.1-192.168.141.254
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.141.192-192.168.141.224/24 expire 1:00
dhcp scope option 1 dns=192.168.141.1
dns service recursive
dns server 192.0.2.81
httpd service off
httpd host none

dhcp scope option無

console character ascii
ip route default gateway pp 1
ip filter source-route on
ip filter directed-broadcast on
ip icmp redirect send off
ip lan1 address 192.168.141.1/24
pp select 1
 pp always-on on
 pppoe use lan2
 pp auth accept chap
 pp auth myname user_id password
 ppp lcp mru on 1438
 ppp ipcp ipaddress on
 ppp ipcp msext on
 ppp ccp type none
 ip pp mtu 1438
 ip pp nat descriptor 1
 pp enable 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 ipcp
nat descriptor address inner 1 auto
rip use off
telnetd service on
telnetd host 192.168.141.1-192.168.141.254
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.141.192-192.168.141.224/24 expire 1:00
dns service recursive
dns server 192.0.2.81
httpd service off
httpd host none

ECPGでSELECT FOR UPDATE

*生保単独* — Mon, 27 Dec 2010 03:01:26 +0900

Windows版のPostgreSQL 8.4に付いてきたECPGでSELECT ... FOR UPDATEをやってみたときの微妙なメモ。まあ、普通に動くので微妙ではないかもしれないですけど。ちなみに開発環境はVisual C++ 2005。

取り敢えず、テスト用に簡単なテーブルを作ってみる。

CREATE TABLE T_TEST (
    TEST_ID SERIAL NOT NULL PRIMARY KEY,
    TEST_STR VARCHAR(8) DEFAULT '' NOT NULL
);

序でに申し訳程度にレコードも足しておく。

INSERT INTO T_TEST (TEST_STR) VALUES ('aaaa');
INSERT INTO T_TEST (TEST_STR) VALUES ('bbbb');
INSERT INTO T_TEST (TEST_STR) VALUES ('cccc');
INSERT INTO T_TEST (TEST_STR) VALUES ('dddd');

以下のようなECPGに食わせるコードを書いてみる。

EXEC SQL
    BEGIN;

EXEC SQL
    SELECT TEST_ID 
     FROM T_TEST 
      WHERE TEST_ID > 0 FOR UPDATE;
...
EXEC SQL
    COMMIT WORK;
...

BEGIN;で明示的にトランザクションを開始してCOMMIT WORK;しているので、プリプロセッサecpg(1)に渡すときには-tオプションを付けます。で、エラーもなくVisual C++ 2005のビルドまで通るのですが、実行するとSQLCODEが-202、SQLSATTEが07002なエラーを吐きます。INTO句がないからなのですが、エラーだからといって別にロックに失敗しているわけでもなくそこでトランザクションがROLLBACKしているわけでもなく正常に動作してたりします。まあ、デフォルトがEXEC SQL WHENEVER SQLERROR CONTINUE;なので処理を続行するのはわかるんですが、エラーって続行可能な場合を指すのかなと。SQLWARNING扱いでも良さそうな気が。兎も角、INTO句を付ければ解消しそうなので付けてみることに。返ってくる行数が事前にわかるわけでもないので、ここはDESCRIPTORを使って以下のように書いてみる。

EXEC SQL
    BEGIN;

EXEC SQL ALLOCATE DESCRIPTOR test_desc;

EXEC SQL
    SELECT TEST_ID 
     INTO DESCRIPTOR test_desc 
      FROM T_TEST 
       WHERE TEST_ID > 0 FOR UPDATE;

EXEC SQL DEALLOCATE DESCRIPTOR test_desc;
...
EXEC SQL
    COMMIT WORK;
...

別にdescriptor areaから値を取り出すわけでもないので何となくもったいない感はありますが特にエラーも吐かず実行できます。勿論、ちゃんとロックもかかります。で、マニュアルの32.7. Dynamic SQLを読んでみると、こんな記述が。

引用:PostgreSQL 8.4.6 Documentation(32.7. Dynamic SQL)

An EXECUTE command can have an INTO clause, a USING clause, both, or neither.

日本語だとここ。

引用:PostgreSQL 8.4.4文書(32.7. 動的SQL)

EXECUTEコマンドはINTO句、USING句、この両方を持つことも、どちらも持たないこともできます。

ん？動的SQLを使うとINTO句が省略できるのか？とか思って以下のようにやってみましたが、

EXEC SQL BEGIN DECLARE SECTION;
    ...
    const char *sfu_stmt 
     = "SELECT TEST_ID FROM T_TEST WHERE TEST_ID > ? FOR UPDATE;";
    ...
EXEC SQL END DECLARE SECTION;
...
EXEC SQL
    BEGIN;

EXEC SQL
    PREPARE test_query FROM :sfu_stmt;

EXEC SQL
    EXECUTE test_query USING 0;

EXEC SQL
    DEALLOCATE PREPARE test_query;
...
EXEC SQL
    COMMIT WORK;
...

同じようにSQLCODEが-202、SQLSATTEが07002なエラーを吐きました。この場合もINTO句は要るようで、

EXEC SQL BEGIN DECLARE SECTION;
    ...
    const char *sfu_stmt 
     = "SELECT TEST_ID FROM T_TEST WHERE TEST_ID > ? FOR UPDATE;";
    ...
EXEC SQL END DECLARE SECTION;
...
EXEC SQL
    BEGIN;

EXEC SQL
    PREPARE test_query FROM :sfu_stmt;

EXEC SQL ALLOCATE DESCRIPTOR test_desc;

EXEC SQL
    EXECUTE test_query 
     INTO DESCRIPTOR test_desc USING 0;

EXEC SQL DEALLOCATE DESCRIPTOR test_desc;

EXEC SQL
    DEALLOCATE PREPARE test_query;
...
EXEC SQL
    COMMIT WORK;
...

とすると特にエラーも吐かず実行できました。ちなみに、動的SQLじゃない場合と同様にどちらも正常に意図した通りに動いてはいます。でも、なんだか「INTO句やUSING句は書かなくて良い場合は書かなくてよい。」と言われているようでなんだか「赤く塗られたところは赤いです。」とか「500円のものは500円です。」と同じような感覚があり、そりゃそうだろうと言いたくなるような仕様ではあります。

後、最新のPostgreSQL 9.0.2 Documentationでもそうなんですが、ずっと、

引用:PostgreSQL 9.0.2 Documentation(32.7. Dynamic SQL)

EXEC SQL EXECUTE mystmt INTO v1, v2, v3 USING 37;

と書かれていますが、:v1, :v2, :v3と書かないと動作しないはず。このあたりからしてECPGってあんまり使われてないんでしょうね。

Phreebird Suite 1.02お試し

*生保単独* — Wed, 17 Nov 2010 19:52:56 +0900

まだまだデモレベルな感じですが、Dan Kaminsky氏ご提供のPhreebird Suite 1.02のphreebirdをお試し程度に使ってみる。大雑把にいえば、DNSSEC未対応のDNSサーバーのレコードに署名を付けてくれるプロキシーのようです。

モノは、

http://s3.amazonaws.com/dmk/phreebird_suite_1.02.tar.gz

あたりにあるようです。後、プレゼンらしきものが、

http://www.slideshare.net/dakami/phreebird-suite-10-introducing-the-domain-key-infrastructure

なんかにあります。

テスト環境は、某βテスト中のクラウド/VPSのCentOS5.5。まずは、インストール。取り敢えず、取得と展開

$ wget \
    http://s3.amazonaws.com/dmk/phreebird_suite_1.02.tar.gz
$ tar xpvzf  phreebird_suite_1.02.tar.gz
$ cd phreebird_suite_1.02

まずは、依存するライブラリとかのインストール

$ su
# sh depbuild.sh
# exit
$

うまくいかなければ、depsディレクトリにcdしてアーカイブ展開して./configure && make && make installとか各々のドキュメントの指示に従う等してインストールします。

そして本体のインストール。

$ su
# make && make install

後は、ldconfig(8)を実行しておきます。

# cat > /etc/ld.so.conf.d/phreebird.conf
/usr/local/lib
# ldconfig

で、使い方。

# phreebird -?

とすると簡単なヘルプが出ます。ZSKを作成します。

# phreebird -g

とするとカレントディレクトリにdns.keyという名前で秘密鍵が出来ます。アルゴリズムはRSASHA1_NSEC3。できるモノはldns-keygen(8)やdnssec-keygen(8)で作られるモノと同じなので、他のアルゴリズムを使いたい場合、そっちで作っても構わないのですが、Private-key-formatがv1.3なモノは使えないようなので、イマドキのdnssec-keygen(8)なんぞで作る場合は-Cオプションを付ける必要があるようです。

後は、適当なコンテンツDNSサーバ(Authoritative Server)を指定して起動します。以下は、適当なコンテンツDNSサーバのIPアドレスが192.0.2.2だった場合。

# phreebird -b 192.0.2.2:53

-bを指定しなければ、ローカルの50053に向くようです。

後は、dig(1)とかで、動作確認。

$ dig +dnssec +multiline @127.0.0.1 example.jp. soa

キャッシュDNSサーバ(Recursive Server)といいますかフルリゾルバに向けてやると漏れなく署名付けてくれたりします。すでに付いているものは署名し直されることになります。
ちなみに、rootのhint fileが設定されていないコンテンツDNSサーバー、たとえば、

zone "." {
    type hint;
    file "/dev/null";
};

になっているものや、zone "."がないコンテンツDNSサーバー^(*1)に向けてやって、

$ dig +dnssec @127.0.0.1 . ns

とかすると、Segmentation faultで落ちます。

*1: コンテンツDNSサーバーって普通そうだとは思いますけど。

cron(8)でZSKを作る件

*生保単独* — Wed, 17 Nov 2010 18:10:04 +0900

引用: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; を試してみる

*生保単独* — Mon, 08 Nov 2010 23:50:27 +0900

所有ドメインを使って、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を含めて、今のところ手放しにおまかせするのは少々躊躇われるところかもしれません。何か使い方を間違えているのかもしれませんけど。

auto-dnssec maintain; を試してみる

*生保単独* — Thu, 28 Oct 2010 14:38:21 +0900

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)。

YAMAHAのルータとDO bit

*生保単独* — Mon, 18 Oct 2010 11:46:27 +0900

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

.jp DNSSEC

*生保単独* — Mon, 18 Oct 2010 02:09:35 +0900

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

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

復活改善？

*生保単独* — Wed, 13 Oct 2010 15:09:28 +0900

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

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

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

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

*生保単独* — Sat, 09 Oct 2010 06:45:11 +0900

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

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

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

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

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

*生保単独* — Thu, 07 Oct 2010 08:14:26 +0900

WebARENA PRO V3

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

第八回吟道祭

*生保単独* — Wed, 22 Sep 2010 02:18:22 +0900

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

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

入場は無料だそうです。

そんなとこに個性要らんから

*生保単独* — Tue, 24 Aug 2010 03:26:32 +0900

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が出来ます。