_ 天気予報では雪の3連休。どこに遊びにいこうかと考えて、平地で中途半端な雪に降られるよりも、いっそ山の中でめいっぱい雪に埋もれた方が楽しいだろ、ってことで裏磐梯。晴れることは期待してなかったけど、ホワイトアウトするようなひどい雪になることもなく、事前の予報のわりにはマシな天気だったんじゃないかな。ルート その1、 その2。
_ イエローフォール。黄色い氷瀑。わしが知ったのはつい最近だけど、けっこう有名らしく団体さんも何組か来てた。ずいぶん小さいように見えるけど、実際小さい:-)。下半分が雪に埋もれてるせいもあるけど。
磐梯山の火口原。木が生えてないところは、凍結した沼(銅沼)。
_ 連休で遊びにいったときのおみやげを近くの席の人に「はい、バレンタインデー」と言いながら配り歩いたときのみんなのイヤそうな顔がすばらしい。
_ つーか女性が足りません。
_ この前ちらっと書いた手前 DTLSについて少しだけ調べてみた。例によって斜め読みだが。
_ …あー、TLS の UDP 版だというのはまあ知ってたけど、UDP なのに TCP の TLS のようにまじめにハンドシェイクするのね。TCP と違って UDP はパケットが到達する保証がないので自前で再送タイマーまで持つとか、えらい複雑な感じ。RFC の中でも書いてあるようにストリーミングとか IP 電話とかネトゲーみたいな用途の暗号化にはいいかもしれんけど、DNS のようにクライアント、サーバともパケット一発ずつ打ちあっておしまい、というプロトコルに導入するにはかなり無理があるなこりゃ。こんなの使うぐらいなら UDP じゃなくて TCP な TLS の上に DNS を通した方がずっとシンプルでオーバーヘッドも小さくなりそう。
_ ldns 1.6.8 の ldns-signzone -n -p で NSEC3 opt-out しようとすると、NSEC3 だけでなく NSEC3PARAM の opt-out flag まで 1 になっちゃう。RFC5155 には NSEC3PARAM の opt-out flag はゼロじゃなきゃダメ、ゼロじゃない NSEC3PARAM は無視しなきゃダメ、と書いてあるのに。バグだよなぁ。ソースを見るとちゃんと考慮されたコードになってるみたいなんだけど、なぜか効いてないみたい。なぜだろうなぜかしら。
_ ldns はあくまでライブラリであって、ldns-signzone とか ldns-keygen とかはそのライブラリを使った実装サンプルでしかないので、サンプルなりの扱いでのぞむのが正しいんだと思う、きっと。
_ 最近ここに書いてる内容からして DNSSEC にひどく肩入れしてるように思われてそうな気がしなくもないので念のため書いておくと、べつにそうでもない。
_ あのね、DNSSEC を失敗なく運用するの、すっげー難しい。対応しないと毒入れされてしまう危険はたしかにある。でも、DNSSEC に対応しないで毒入れされる危険よりも、DNSSEC のオペレーションに失敗してドメイン丸ごとインターネットから消失してしまう危険の方がはるかに大きい。リスクを回避するのは重要なことだけど、そのためにもっと大きなリスクを抱えこむのは本末転倒。
_ 権威 DNS (コンテンツサーバ)の DNSSEC は、ほんとやめたほうがいいと思う。会社のエラい人から命令されても、手に負えないので逆に危険ですと言い返しましょう。うかつに手を出すと噛みつかれます。DNSSEC ってのは素の DNS を正しく理解して正しく運用できてるというのが大前提なのに、そのレベルですでに怪しいところがひじょーに多いわけ (*1)。それをクリアした上で、さらに加えて膨大な知識を新たに覚えなきゃいけなくて、日々の運用もめんどくさく、いざトラブルが起きたときの対処も従来の DNS に比べてひじょーに難しい、とやたらコストが高い。本業がほかにあって片手間で DNS も管理してるとかいう程度の人であれば、ほんとやめましょう。本業に手がまわらなくなるよ。
_ それでもどうしても毒入れの危険を排除したいのであれば、自分でやらずに信頼できる DNS ホスティング屋や SIer に運用を任せましょう。ここはケチってはいけない。金ではなく自分の手間の方をケチるべき。TLD のレベルでもミスオペがときどき起きてるぐらいで、ましてや素の DNS でもダメ業者がてんこもりの現状でよそに任せるのも不安ではあるけど、何年かすればノウハウが蓄積されて安心してアウトソースできるようになるはず。たぶん。きっと。そうなるといいな。死ぬ気で勉強してください > 業者さん
_ 参照 DNS (キャッシュサーバ)の DNSSEC 対応はそれほど難しいことはないし、トラストアンカーの自動更新をちゃんと設定しておけば以後放置できるので、まあこっちはわりと気軽に手を出せる。が、それは手を出していいというのとは別次元の話。あるドメインの名前解決が突然できなくなった、なぜだ、というときに原因追求できるまでの知識を身につけようとしたらけっこうたいへん。名前解決できないのが取引先だったりするとその間業務が止まってしまうリスクも出てくる。ロールオーバーにしくじったとか再署名忘れて期限切れ、みたいなミスならよそでも同じ症状が出てるはずなんで、自分で調べずに twitter でつぶやくなりどっかの Q&A サイトで質問するなりして調査を他人に任せてしまうのもひとつの手だけど、UDP フラグメントなパケットが通らない、みたいな特定の条件のときだけ発動するネットワークまわりの問題だったりすると他人はほとんどアテにできないだろう。
_ うちは権威 DNS でも参照 DNS でも DNSSEC をやらない、と決めた場合でも知っておくべきこと(やると決めた場合も当然知っておくべきこと)。TLD のレベルで DNSSEC がコケると、DNSSEC 対応の参照 DNS からは DNSSEC 導入済みのドメインだけでなく未導入のドメインまで含めてその TLD が全滅したように見える(つまり JPRS がミスると .jp がインターネットから消える)。これは「もし起きたら」という仮定の話ではなく、.se や .uk などで実際に起きたことがある。DNSSEC と関わりあいになるつもりがまったくなくても、自分のところの運用が完璧でも、そういう事故のときは dnssec validation してるよそのサイトから自分のところにアクセスできなくなって他人事ではいられなくなるということは注意しておいた方がいい。あと、 qmail の問題も対処してね。
_ と、さんざんこきおろしてみたけれど、だから DNSSEC はいらない、というつもりはない。難しいからよほど自信がなければ手を出すな(あるいは外部委託しろ)と言ってるだけで、正しく理解していて、かつコスト増を受け入れられるのならばそれを止める理由は何もない。素の DNS ですら正しく運用できてないのに流行りだからといって DNSSEC に手を出すと痛い目にあうよ、ちゃんと基礎から固めていけ、というだけのこと。DNSSEC は義務でもなんでもないんだから、できもしないことをやる必要はない。もちろん、ちゃんと運用できるだけの力量があるのならば、横並びでみんないっせいに、なんて性質のものじゃないんだしほかに遠慮せずどんどんやればいい。
_ ってゆーか、署名鍵を KSK と ZSK に分離するっての、あれ煩雑なんでやめた方がいいんじゃないかなー。煩雑ってのは運用ミスの危険性が増すってことだよ。ZSK を使わず KSK でゾーン全体を署名するやりかた (*2)の方が、管理しなきゃいけない鍵が半減するので事故も減るんじゃないかなと思う。そのへんの手間を自動化するツールを使えばどっちでも手間はたいして変わらんだろうけど、それでも裏で何がおこなわれているかは知っとく必要はあるわけで、それを理解するにはやっぱり鍵1個の方がシンプルでずっとわかりやすいと思うんだよね。
(*1): 何度もネタにさせてもらって申し訳ないけど、 こんないいかげんな理解のまま DNSSEC をやると、ロールオーバー中に名前解決できなくなる事故が間違いなく起きる。
(*2): ZSK に SEP フラグを立てて KSK を使わない、という方が正しい表現のような気もするが、実質的にはどっちも同じこと。
_ ところで BIND 9.7.3 が出てるけど、バグ修正だけで新機能がひとつもないのに、なんで 9.7.2-P4 ではなく 9.7.3 なんだろう。