_ かなりマイナーな root CA。初めて知った。どのくらいマイナーかというと、たいていの環境では CA 証明書がインストールされてなくて ここにアクセスすると警告されるぐらいにマイナー。
_ Windows 7 ではデフォで入ってるみたいだけど、少なくとも XP では「ルート証明書の更新プログラム」が必要で、しかし Windows update でもオプション扱いで自動ではインストールされない(vista は知らん)。ここの CA 証明書を持ってる環境であっても、Firefox は OS に入ってるルート証明書は無視して自前の証明書リストを使う(そしてその中に含まれていない)ので警告される。MacOSX では Snow Leopard でもダメ。FreeBSD の /usr/ports/security/ca_root_nss は mozilla 由来のものなので当然ダメ。CentOS の /etc/pki/tls/cert.pem にも入ってない(ので、RHEL もたぶんダメ)。確認してないけど、各種携帯電話の内蔵ブラウザもたぶんダメだろう。
_ すべてでないとはいえ Windows では標準装備のバージョンもあるわけなので、規準をクリアして認定取得済みの信頼していい CA だと思うんだけど、そうはいってもここから発行された証明書を正しく検証できない環境が大多数で、そういうところにとってはオレオレ証明とたいして変わらん。えーと、 この区分によると第五種だな。こういう CA から発行された証明書を金を出して使う意味ってないよなぁ。…とかいうのは、新規参入の阻害でしかなくて、排除してしまうのはよろしくないんだけど、しかし、apple とか mozilla とか、ルート証明書込みの製品を出荷してるベンダーに自分とこの CA 証明書も含めてもらうよう根回し(あるいは営業活動)とかしないんだろうか。
_ で、なんでこの CA のことを知ったかというと、messagelabs.com がこの CA で発行された証明書を使っていて、ここにホスティングされてるドメインにメールを送ったら TLS のネゴで untrusted issuer で警告されたから。messagelabs ってメール屋さんではかなりの大手なんだけど、こういう使えねぇ証明書でも気にせず使っちゃうんだとちょと驚いた。メールでの SSL って、暗号化よりもむしろ送り先が詐称じゃなくてホンモノかどうか確認できることがメリットなわけで、なのにその検証にコケちゃうような証明書を使ったらいかんよなぁ。
_ まあ、messagelabs ってこんなクソいいかげんな SPF レコードを書いて平気でいるところでもあるので、何をしてても不思議ではないともいえるんだけど。
> host -t txt messagelabs.com messagelabs.com descriptive text "v=spf1 +all"
_ 7/15 に root zone が DNSSEC 署名されるわけですが。日本時間だとたぶん16日になるかな。今日は某所で DNSSEC なセミナーもあったし、来週も品川であるし、どんどん本格導入が近づいてきてる。本心は、仕事増やすなめんどくさい、なんだけど。障害を起こさず運用するには複雑すぎる。
_ 問: 最近の BIND とか Unbound とかってデフォルトで DNSSEC 有効だと聞くけど、root 署名がはじまる前/はじまった後に何かした方がいいのか。放置してて問題はあるのか。
_ 答: 気にしなくてよし。今すでに root zone に「ウソの署名情報」が存在してるけど (*1)、何も問題起きてないでしょ。ウソの情報がホンモノになるだけ。「署名される」ということと、それを「検証する」ということはまったく別の話。たしかに BIND、Unbound では DNSSEC 検証がデフォで有効になってるけど、それだけじゃ足りない。検証に必要な情報(トラストアンカー; DNSSEC におけるヒントファイルみたいな役目)を手で設定するまでは実際には DNSSEC の検証はおこなわれないので、それをしないかぎりは以前のまま何も変わらない。地雷原にあえて踏み込もうとしないかぎり、地雷を踏むこともないということ。
_ root zone の署名は RSA SHA-256 でおこなうとアナウンスされてて、ところがこれを理解できる DNS 実装がぜんぜん普及してない(BIND 9.6.2 以降、Unbound 1.4 以降)ので、気にするまでもなくほとんどのところでは検証できない。そもそも、トラストアンカーをどうやって公開するかとかいう話がまったく聞こえてこないので、地雷原に侵入しようにもできない(今日 JPRS の人にも確認したけど知らんと言ってた)。
(*1): こんな感じ。% host -t dnskey . . has DNSKEY record 256 3 8 AwEAAa2Yy++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8 . has DNSKEY record 257 3 8 AwEAAa7hd++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
_ さっそく unbound.conf に root の trust anchor を仕込んでみた。named.conf の方にも仕込んでみようかとも思ったが、そういえば手元の BIND は SHA256 を理解できないバージョンなのでやめた。
_ flags の ad が DNSSEC の検証に成功しているという印。
> dig +dnssec . ns ; <<>> DiG 9.6.1-P1 <<>> +dnssec . ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9653 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518339 IN NS a.root-servers.net. . 518339 IN NS g.root-servers.net. . 518339 IN NS c.root-servers.net. . 518339 IN NS b.root-servers.net. . 518339 IN NS h.root-servers.net. . 518339 IN NS k.root-servers.net. . 518339 IN NS d.root-servers.net. . 518339 IN NS l.root-servers.net. . 518339 IN NS j.root-servers.net. . 518339 IN NS m.root-servers.net. . 518339 IN NS f.root-servers.net. . 518339 IN NS e.root-servers.net. . 518339 IN NS i.root-servers.net. . 518339 IN RRSIG NS 8 0 518400 20100722000000 20100714230000 41248 . ohs6B6xof3LrglEMni5/gz9NY5M8MWx0qNVpzo8SmzdqhA4gUGTzHW2O 9kz7ZqZLZq6LXUF2Qg2eYoY9rfBjajq0PSZIzkpwWGVIF2hQnbtiDUwS RR/RliyBUsGyvom7LNug+527vQCCEu9GNWS9rSgqo2HY44+CYjqo0mpF Y58= ;; Query time: 1 msec ;; SERVER: 192.168.1.21#53(192.168.1.21) ;; WHEN: Fri Jul 16 10:37:37 2010 ;; MSG SIZE rcvd: 397_ unbound.conf の設定内容は以下。トラストアンカーは ここから。
trust-anchor: ". DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"_ すでに DNSSEC 対応が完了している既存の TLD (.se とか .org とか) の DS レコードは登録されていない模様。つまり、あくまで "." ゾーン自身が DNSSEC 対応しただけで、下位ゾーンとの信頼の連鎖は構築されていない。これらも DNSSEC で検証したければこれまでどおり 個別にトラストアンカーが必要。
_ ツッコミいただきました。.br とか .bg とか、一部の TLD は DS が登録されてるって。
ほんとだ。DS のある TLD とない TLD って何が違うんだろ。> dig br. ds @a.root-servers.net +short 41674 5 1 EAA0978F38879DB70A53F9FF1ACF21D046A98B5Croot のトラストアンカーをひとつ指定するだけで下位ゾーンまで DNSSEC の検証が成功しました。> unbound-host -v -y '. DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5' a.dns.br a.dns.br has address 200.160.0.10 (secure) a.dns.br has IPv6 address 2001:12ff::10 (secure) a.dns.br has no mail handler record (secure)
_ system() で外部コマンドを呼びまくるだけで、それ以外に大して複雑なことはしないような スクリプトは素直に sh で書くべきだ。
_ いつものように車中泊して目指すは北アルプス(の南の方)。
_ 7/17。自転車乗りにとって、山登りといったらやっぱり乗鞍だよね。わしゃヘタレなのでバスに乗ったけど(←オイ)。わしが今までに登ったいちばん高い山って日光白根山の 2578m で、これでも関東以北の最高峰なんだけど(しかもロープウェイを使わずに登った)、それより高い 2702m の畳平までバスで連れていってくれちゃうってのはなんだかガッカリだよね(←文句あるなら自転車で登れ)。
_ ということで、乗鞍岳の主峰、標高 3026m の剣ヶ峰まで。数字の上では 3000m 級の山なんだけど、畳平から山頂までの標高差は 300m、たったの1時間半で登れちゃう楽ちんな山。はじめは青空も見えてたんだけど、どんどん雲が出てきて、 山頂に辿りつくころには空はまったく見えず。視界はそれほどよくないし、何より行程がラクすぎていまいち感動に欠ける。そして下山をはじめてすぐに雨が降りはじめ、ほどなく土砂降りに。お手軽だからといって雨具も持たずに手ぶらで山に登るようなアホがたくさんいたけど(サンダル履きなんてアホもいた)、彼らは大変な目にあったようですね(他人事)。休日の昼間で人がたくさんいて、わざと登山道からはずれるかよほど濃い霧になるか雷に打たれでもしないかぎり遭難のしようがないだろうから、体の芯が冷えきるまで反省すればいいと思います。
_ バスの時間まで お花畑を散歩した後、麓に降りて 三本滝(合成写真じゃないよ)、善五郎の滝を見物して、お風呂。汗を流して出てくると日暮れ。事前の予想どおり、こんな山の中には夜に営業してるレストランもコンビニもなかったので(よくよく探せばあったかもしれんがそこまでする気にはならず)、持参したお料理セットでてきとーに自炊しておやすみなさい。
_ 7/18。朝からまたバスに乗るよ。今度の行き先は上高地。 早朝の大正池は朝霧に包まれて幻想的な雰囲気…どころじゃなくて霧が濃すぎてなーんにも見えない。きのうの乗鞍に続いてガッカリお天気か、と嘆きながら歩いているうちに、 だんだん霧が晴れてきて(田代湿原)、 だんだん視界がよくなってきて、そしてそしてしまいには360度まったく雲のない完全な青空！ 穂高連峰の山稜がくっきりはっきり見える。ほんとすばらしいお天気でたいへん気持ちいい。陽射しのあるところは景色がよくて気持ちいいし、 木陰はひんやりしててやっぱり気持ちいい。どこをとってもすべてすばらしい。あんまり気持ちいいもんだから、明神橋のそばの日のあたる河原で2時間近くのんびり飯を食ったりお茶したり昼寝したり柳の綿毛が飛ぶ様をぼーっと眺めたりしてたらすっかり日焼けしてしまった。肌がひりひりする。
_ 昼寝してるうちにちょっと雲が出てきたようで、上高地を取り囲む山々のてっぺんはおおかた雲の向こうに隠れちゃったけど、それでも青空なのは変わりなく。大正池まで戻ってきたら、あたりまえだが朝とは違って今度はちゃんと景色が見える。これだけ晴れてりゃ上等なんだけど、それでも先刻までのかけらほどの雲すらない青空の後なので、雲が出てるのが残念だ。
_ 上高地を後にしたら風呂に入って寝る場所の確保。夏の車中泊は暑いので、できるだけ涼しいところじゃないと。ということは、やっぱりあそこしかないね。上高地とは松本を挟んで正反対の位置にある、美ヶ原高原の道の駅。標高 2000m。夜7時半に到着したら、夏だけど、ぶっちゃけ寒い。ここで寝るのは2回目なのでわかってたしちゃんと備えもあるけど。この前の夜は曇ってたけど、この夜はど近眼のわしでもたくさんの星が見える。いい空だ。
_ 7/19。美ヶ原高原の朝は、見事に快晴。きのうの上高地とは違って空高くに巻雲が若干あるけど、この程度はまったく問題ない。そして、きのう以上に陽射しが強い。車中泊は2回目だけど、それ以外に何度も来てるので、まあてきとーにビーナスライン沿いをのんびり走り、 八島ヶ原湿原をのんびり歩いてぐるっと一周。霧ヶ峰、車山の付近はびっくりするほどニッコウキスゲが咲いて*なかった*。7月の3連休にこのあたりに来るのはたぶん3回目だけど、今年はずいぶん遅いのかね。あとは蓼科経由で麦草峠を通って、 白駒池を見物して、そろそろいい時間なので帰路につく。ふつーなら中央道で帰るのが正解だけど、どーせ渋滞してるだろうし R20 に逃げてもやっぱり渋滞してるだろうし、ということで、千曲川沿いに群馬の方に抜けていく。関越もどうせ渋滞なのでずっと一般道で。つーことで、3日間合わせて車が 730km、徒歩が 30km ぐらい。
_ 梅雨が明けたのはいいけど、熱帯夜はどうにかならんものか。
_ こうすればできるはず、というメモ。BIND の本家 ISC からも ドキュメントが出ているが、決してそのままコピペしてはいけない。なぜなら、trust anchor が正しいものかどうか検証するという過程がごっそり抜けているから。それをやらなきゃ DNSSEC の意味がまったくないでしょうよ。このドキュメントを置いているサイトがどっかの誰かによってウソの情報に書き換えられたりしたら、それをコピペして設定したサイトが危険に晒される。まあ実際にはそんなことはまずないだろうから、最終的にはコピペしたのと同じ結果になるはずなんだけど、じゃあコピペでいいや、というのは違うんだよ。
_ まず、PGP なり GnuPG なりを入手して使える状態にする。必ず信頼できるサイトから入手すること。このへんは BIND じゃなくて PGP の問題なので詳しい説明は略。
_ BIND 9.6.2 以降または 9.7.1-P2 以降を入手する。ソースだけでなく、PGP/GnuPG でソースの署名が正しいこともチェックする。コンパイルしてインストールし、dnssec 以外の部分をふつーに設定して動くようにする。具体的なことは略。
_ ここからやっと DNSSEC の設定。まず、root zone の DNSKEY を入手してファイルに保存する。DNSSEC の鍵には ZSK (ゾーンに署名するための鍵)と KSK (ZSK に署名するための鍵) のふたつあって、KSK/ZSK 双方の公開鍵が DNSKEY として登録される。今回必要なのは KSK の方だけ。256 なのが ZSK で 257 が KSK。
9.7 ではいちいち ZSK を消さなくても勝手に無視してくれるみたい。ファイル名は、必ず *.key にすること。なぜだか知らんが、ほかの名前だと後でエラーになる。この時点ではまだ DNSSEC は有効ではないので、dig で取得した値が改竄されていない保証がない。よって、以下でそれが正しいか検証する。> dig dnskey . > root.key > vi root.key # 256 な方をコメントアウトするか消す_ DS を作る。DS は KSK のハッシュなので、DNSKEY から生成できる(が、逆はできない)。生成には、それ専用のツールを使う。
-2 は SHA-2 なハッシュを出力せよ、な意味。root zone は SHA-2 なので(root 以外は SHA-1 もある)。ファイル名が *.key じゃないとここでコケる。9.7 だと *.key じゃなくても> dnssec-dsfromkey -2 root.keyとすることで可能っぽい。で、その実行結果はこうなる。> dnssec-dsfromkey -2 -f filename .. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5_ で、この出力と、 公開されているトラストアンカーが一致しているかどうか確認する。ファイル形式が異なるので diff ってみるわけにはいかないけど、どうやって見ればいいかはわかるでしょ。もちろん、root-anchors.xml が正しいかどうかを PGP/GnuPG で確認すること。
_ 一致していれば、dig で取得した DNSKEY は正しかった、ということ。この DNSKEY の値を named.conf に設定する。具体的な設定方法は ISC の説明どおりでよい、はず(ここから先はまだ試してない)。ただし、実際の設定値はこのページのものをコピペするのではなく、自分で確認したものに置き替えること。この後 rndc reconfig すれば DNSSEC validation が有効になる。トラストアンカーが一致しなかった場合、どっかでネットワークを流れるデータを改竄してる輩がいる可能性がある。それを排除してもう一度はじめから(PGP のインストールから)やりなおし。
_ せっかく作った DS は、確認完了した時点で用済みなのでポイしてよい。BIND は DNSKEY 形式しか使えないので、DS 形式のトラストアンカーは確認用途にしか使わない(自分のゾーンを DNSSEC で署名する場合にはもちろん活躍する)。unbound は DNSKEY と DS のどっちの形式でも食えるので、こんなめんどくさいことしなくても、はじめから DS 形式で公開されているトラストアンカーを コピペするだけでよい(もちろん、それがホンモノかどうかの確認は必要)。なんで DS 形式でしか公開しないんだろうか。DNSKEY 形式でも公開するべきだと思うんだけどな。手間の問題というより、この手順を正しくこなせる人ってそうそういないでしょ。
