will♪++

対象のドメイン

mimuret.net
mimuret.org
mimuret.jp

チェック結果

T2000がオクで安く手に入ったので、ベンチマークしてみた。

T2000にはUltraSPARC T1っていうちょっと古いけど面白いCPUがのかってます。
簡単に言うと、1CPUに最大8core入ってるCPUで、さらに1coreあたり4スレッド、つまり1CPUで最大32スレッドさばける化け物です。
ただ、1スレッド辺の処理能力がめっさ低いので、非常に用途を選ぶCPUです。
重い処理をさせるというかは、軽い処理をたくさん同時にこなすためのサーバです。
ほかにも暗号化チップを1個内蔵してたりします。（今日はこっちのベンチ）

今回主に測定するのはRSAのベンチマークです。

某会合でも発表したのですが、T1チップで暗号化使うときは暗号化モジュールを使わないと使いものになりません。

DNSSECはじめると、RSA処理結構発生するので、このベンチが重要になってくるんですね。

んで、主に着目するのはRSA1024のsignとverify、署名と検証です。
権威サーバではゾーン署名する際に今は大体RSA1024で署名していると思います。
また、リゾルバのバリーデータのほうも署名が大体RSA1024なので、これを検証している筈です。
（KSK部分は2048が多いですが省略）

検証は暗号化チップのNCPを使用するかしないか、フォークするかしないかの
計４種類を行いました。
また、この子は4core16threadの機械なので、フォーク数も１６にしてます。
ということで、検証開始ー

■NCP有り シングルスレッド
openssl speed rsa -engine pkcs11
sign verify sign/s verify/s
rsa 512 bits 0.000049s 0.000042s 20502.6 23622.6
rsa 1024 bits 0.000053s 0.000044s 18823.5 22487.7
rsa 2048 bits 0.000063s 0.000048s 15808.3 20719.4
rsa 4096 bits 1.087000s 0.020833s 0.9 48.0

■NCP有り 16 Forked
openssl speed rsa -engine pkcs11 -multi 16
sign verify sign/s verify/s
rsa 512 bits 0.000045s 0.000029s 22210.8 33991.6
rsa 1024 bits 0.000176s 0.000050s 5682.8 19928.1
rsa 2048 bits 0.000992s 0.000126s 1007.8 7962.4
rsa 4096 bits 0.146369s 0.002720s 6.8 367.6

■NPCなし シングルスレッド
sign verify sign/s verify/s
rsa 512 bits 0.002791s 0.000274s 358.3 3653.8
rsa 1024 bits 0.016584s 0.000920s 60.3 1086.9
rsa 2048 bits 0.113864s 0.003434s 8.8 291.2
rsa 4096 bits 0.839167s 0.013351s 1.2 74.9

■NCPなし 16 Forked
openssl speed rsa -multi 16
sign verify sign/s verify/s
rsa 512 bits 0.000335s 0.000034s 2981.3 29687.7
rsa 1024 bits 0.002044s 0.000119s 489.2 8432.3
rsa 2048 bits 0.014073s 0.000431s 71.1 2322.5
rsa 4096 bits 0.106086s 0.001630s 9.4 613.6

NCP流石すぎる。
ただ、T1は暗号化モジュールがCPU1個あたり１個しかないのでフォークすると
遅くなるという…T2000っぽくない挙動がおこるのが悲しい
NCP使わないと非常に残念な結果に…T1チップっぽい
ちなみに、現在は後継のT2、T3ときて現在はT4になってます。
T2以降は暗号化チップがコアごとにあるので、さらに速い値になる筈…（けんしょーき欲しい）
ちなみにT1のNCPは2048bitまでしか対応してないので、4096は劇遅です。

次は家に転がっていたXeon X3230な機械で実験！
こいつは4core 4threadなのでフォーク数４個でやります。

■シングルスレッド
sign verify sign/s verify/s
rsa 512 bits 0.000514s 0.000039s 1943.6 25722.8
rsa 1024 bits 0.002133s 0.000094s 468.9 10662.0
rsa 2048 bits 0.010858s 0.000276s 92.1 3617.9
rsa 4096 bits 0.064903s 0.000889s 15.4 1124.9

■4 Forked
sign verify sign/s verify/s
rsa 512 bits 0.000129s 0.000010s 7736.9 102564.1
rsa 1024 bits 0.000534s 0.000024s 1872.5 42441.2
rsa 2048 bits 0.002712s 0.000069s 368.8 14479.7
rsa 4096 bits 0.016262s 0.000225s 61.5 4446.1

xeonはええええーーーーー
verifyは流石にXeon早いっすね。
ただ、同時にNCP有りのRSAのsignがいかに早いか分かるかと思います。

■なんとなく構築時に考えてたこと。
現状ゾーン署名鍵のbit数は1024でというのが主流だけど近い将来2048bitになるよねー、それでもこの構成で大丈夫？HSMとかやっぱりいるんじゃ＞CPUのHW暗号化おいしいです。

なんか、天の声でdnssecのvalidationしてるかどうか分かるといいよね的な
電波を受信したので作ってみた

http://test.dnssec.mimuret.jp/

構成はこんな感じ

-------------------------
リゾルバ
-------------------------
|
| req
|
-------------------------
testns.mimuret.jp
-------------------------
|
| req proxy
|
-------------------------
うちのhidden master
-------------------------

testns.mimuret.jpでリゾルバからのリクエストを受信して、
基本的には後ろにいるhidden masterにクエリーをプロキシーします。

ただし、test.dnssec.mimuret.jpのA/AAAA/TXTレコードのリクエストの場合だけ、細工します。

そのリゾルバのはぢめてのくえりーの場合は、RRSIGなしのダミーレコードを返します。
このとき、リゾルバがバリデーションしてなければ結果を受け入れるはずです。

バリデーションしている場合は、DNSKEYを聞いてきます。そうしたらプロキシサーバの内部のフラグ(DNSKEY聞きにきたよ）が立ちます。
んで、SERVFAILになります。残念

２回目聞きにきた際はフラグが立っているので、普通にプロキシさせます。
hidden masterのほうは普通に署名したRRを返してくるので、これを普通にリゾルバに返します。これはValidation Successfulですねー。ということでこの結果がはいります。

といった、感じで、バリデーション有無で違うレコードを返せるので判定できるのですが、
細かい実装までは考慮してないので、うまくいったり、行かなかったりします。

当初はdo bitで判定すればいいじゃん、と思っておりましたが、どうもbindさんはデフォルトでdo付きで聞いてくるようになっているので、この方法では判定不能です。
この実装の名残で、digをうつと分かるんですが、doなしだとかならずダミーレコードを返すようになってます。

ちなみに、proxy部分はperlのNet::DNSで作りました

mimuret.jpもDNSSEC Readyにしました。

ちなみに、ZSKを一ヶ月に一回CRONで生成
署名もCRONで一週間に一回おこなう感じです。
商用サービスだと、こんなんじゃダメですが。まぁ個人用だしいいかなと。

いまのところ、mimuret.jp/mimuret.net/mimuret.orgが署名済みです。

root@intra-dns02:~# dig +dnssec mimuret.jp

; <<>> DiG 9.8.0-P2 <<>> +dnssec mimuret.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30280
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mimuret.jp. IN A

;; AUTHORITY SECTION:
mimuret.jp. 222 IN SOA ns.mimuret.net. mimuret.gmail.com. 1317550673 3600 3600 3024000 300
mimuret.jp. 222 IN RRSIG SOA 8 2 3600 20111012091753 20111002091753 33600 mimuret.jp. Im6lCzFZq7a3PhxInIyWXQUUQSS3VX5KdIjoxhy6GoA9+WG2Yimpw5cI hSarNodO89ok0a2fqmHHIgZ4RAcvxy2cYpuDmCe+XR3AGeuxw1/2ous2 fKSH2dpQ44ZQPj//f4DhRiThcXhB9qixjZqN6zDMKeEBMyO4LR7rggPL w7M=
5UF8D501KDNK8P14PLAOIP015UPEK3FP.mimuret.jp. 222 IN RRSIG NSEC3 8 3 300 20111012091753 20111002091753 33600 mimuret.jp. hcyv44TL49D1i4YZAlUBaWJY0zdwpX2/awMfZbpUEZgr/YRToYpUtDBa BBwdMnFT+rpcE2qzqSRbltNaQeqErivKH1Py9aYaKsVD/JImQdlkkntB J5IMlpGMm5A51gtysimf2IAYF8GC6wA1wLU3UoFA1cXXspKGUMSs7Rmg e5g=
5UF8D501KDNK8P14PLAOIP015UPEK3FP.mimuret.jp. 222 IN NSEC3 1 0 5 4704 P6OIBPECCVL27N1V08HP2JDB3JM1AHFG NS SOA RRSIG DNSKEY NSEC3PARAM

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 6 22:17:36 2011
;; MSG SIZE rcvd: 528

Continue reading

早速ですが、１年もしないうちにHDDが一本いきました。
mimuret@hac01:~# zpool status
pool: npool
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
repaired.
scan: resilvered 55.2M in 0h2m with 0 errors on Tue Mar 15 20:35:36 2011
config:

NAME STATE READ WRITE CKSUM
npool DEGRADED 0 0 0
mirror-0 ONLINE 0 0 0
c5t5d0 ONLINE 0 0 0
c5t3d0 ONLINE 0 0 0
mirror-1 DEGRADED 0 0 0
c5t1d0 FAULTED 0 0 0 too many errors
c5t2d0 ONLINE 0 0 0
logs
c5t4d0 ONLINE 0 0 0

ということで、交換しました。

mimuret@hac01:~# zpool status
pool: npool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scan: resilvered 55.2M in 0h2m with 0 errors on Tue Mar 15 20:35:36 2011
config:

NAME STATE READ WRITE CKSUM
npool DEGRADED 0 0 0
mirror-0 ONLINE 0 0 0
c5t2d0 ONLINE 0 0 0
c5t3d0 ONLINE 0 0 0
mirror-1 DEGRADED 0 0 0
c5t1d0 UNAVAIL 0 0 0 corrupted data
c5t4d0 ONLINE 0 0 0
logs
c5t1d0 ONLINE 0 0 0

errors: No known data errors

あれ？c5t1d0がおかしい……
どうも、ばらして、交換したときに違うポートにさしたみたいです。
で、元mirror-1のc5t1d0だけが、新しいディスクになっているので、ここに対応するドライブ情報がなくてこんな表示になっているのかな？

ということで、detach

zpool detach npool c5t1d0
mimuret@hac01:~# zpool status
pool: npool
state: ONLINE
scan: resilvered 55.2M in 0h2m with 0 errors on Tue Mar 15 20:35:36 2011
config:

NAME STATE READ WRITE CKSUM
npool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c5t2d0 ONLINE 0 0 0
c5t3d0 ONLINE 0 0 0
c5t4d0 ONLINE 0 0 0
logs
c5t1d0 ONLINE 0 0 0

んでもって、新しいディスクのc5t５d0をattach
zpool attach npool c5t4d0 c5t5d0
mimuret@hac01:~# zpool status
pool: npool
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Thu Apr 28 22:46:56 2011
22.6M scanned out of 1.33T at 797K/s, 496h5m to go
9.85M resilvered, 0.00% done
config:

NAME STATE READ WRITE CKSUM
npool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c5t2d0 ONLINE 0 0 0
c5t3d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c5t4d0 ONLINE 0 0 0
c5t5d0 ONLINE 0 0 0 (resilvering)
logs
c5t1d0 ONLINE 0 0 0

たぶん、ディスク外す前にdetachするのが正しい作法な感じ。
普通はホットスポットで運用していると思うので、レアケースだとは思います。

元ネタ
http://marcblanchet.blogspot.com/2010/08/ipv6-pppoe-on-macosx.html

ターミナルで
sudo sysctl -w net.inet6.ip6.accept_rtadv=1
を実行し、PPPoEv6とかPPTPを実行するとPPP上でRA受け取れる。

ただし、再起動すると戻るので、
sudo vi /etc/sysctl.conf

net.inet6.ip6.accept_rtadv=1

を追加しておく。

また、ルーティングがないので、
/sbin/route add -inet6 default -iface ppp0
でデフォルトルートを設定する。
これも、再接続すると消えるので
sudo vi /etc/ppp/ipv6-up

#!/bin/sh

/sbin/route add -inet6 default -iface ppp0

sudo vi /etc/ppp/ipv6-down

#!/bin/sh

/sbin/route delete -inet6 default -iface ppp0

sudo chmod +x /etc/ppp/ipv6*

DNSSEC導入にあたっての特に注意したほうがいい点を独断と偏見でまとめてみた。
※気づいたら追加します。

-ENS0への対応
EDNS0が必須です。特に古いFWの場合は、ファームの更新が必要な場合も

-KSK鍵交換の運用
鍵に有効期限が設定されている場合は、確実に有効期限までにKSK鍵が更新できる必要があります。また、自動でパッチで行う場合も、レジストリ側のIFがメンテ中な可能性もありますので、成否判定も必要です。（ギリギリの更新はNG、最低でも２週間前に交換する）

-署名の運用
ゾーンの署名には有効期限が設定されてます。
KSK鍵の更新と違い、外部影響は受けにくいですが、何らかの理由で署名失敗する可能性もあります。また、署名回数も多いため、おそらく自動で処理される方がほとんどだと思いますが、成否判定が必須です。


-qmail問題
qmailの仕様上？の問題でDNSを引くときANYレコードを引く。このとき512バイトを超える応答は正常に処理されないバグがある。ANYレコードを引くと、RRSIGもくっついてくるので余裕で５１２バイト超えて名前解決ができず、メールが送れない。また、一連の動作はすべて送信側でおこるため、受信側(DNSSECを有効にしているドメイン）では検知すらできない。
（TXTレコードやらAAAAレコードが今後広がると思うので、DNSSECに限らずおこる可能性がありあます）