_ qmail 512バイト問題の件、JPRS からも アナウンスが出ましたな。
_ この問題は DNSSEC によって発現しやすくなったけれど、DNSSEC が原因ではないので念のため。あくまで qmail の側のバグで、DNSSEC をやってないサイトにメールを送るときでも条件さえ揃えば起きる。たとえば、microsoft.com や apple.com は DNSSEC 未対応だけど、どちらも ANY で512バイト以上返すので未パッチの qmail ではメールを送れないはず。とっととパッチを当てるか qmail 以外に乗り換えてくださいまし。
したがって、全部とはいいませんが、必要なホスト（/128）を個別に設定し、割り当てられたブロック/64とか/48全体に対しては同じ応答を返すように*を使った逆引き設定をすることになるかと。正逆一致チェックに対してはNGですが。えー。ワイルドカードはないわ。書いてあるとおり、double reverse lookup (paranoid check) でコケる。逆引きは名乗るだけならいくらでも嘘をつけて、whitehouse.gov だろうがなんだろうが好きにできちゃう。それをさらに正引きして確認するからこそ、アクセス制限その他有効な利用法が生まれるわけで、一致しないなら害悪以外のなにものでもない。逆引きはかならずしも必要でないと思ってるけど、だからといっていいかげんでいいわけじゃない。やるのであればちゃんとやらなきゃ。スパム対策やウェブのアクセス制御で、接続しにきたユーザーのIPアドレスの逆引き登録があるかないか？さらに正引き逆引きが一致するか？をチェックしてスパム判定する手法があります。たしかに、これ単体で完全にスパムを止めることはできないですし、オーバーブロックする副作用もありますが効果は大きいのも事実です。ちゃんとした使い方をすればこの手法で救われたメールサーバーの管理者の方も多いと思います。正逆一致しない逆引きでいったいどれだけの MTA をごまかせるんだろうか。sendmail の FEATURE(require_rdns) も postfix の reject_unknown_client_hostname も、どちらも逆引きが存在するだけじゃダメで、正引きと一致しないと蹴る。逆引きワイルドカードは何の効果もない。MTA だけでなく、.htaccess や hosts.allow なんかでも同じ。逆引きだけならいくらでも嘘をつけるんだから、アクセス制限の用途で double reverse lookup せず逆引きだけ見るのはセキュリティホールといっていい。それ以外の用途であればもしかしたら用が足りることもあるかもしれないけど。_ そもそも、逆引きはいったい誰のために登録するのか。他人への便宜なのか。違うでしょ。自分たちが管理しやすくするためでしょ。であれば、その手段は DNS に限る必要はない。小さなネットワークでは /etc/hosts で足りるかもしれないし、人によってはエクセルの表で十分かもしれない。DNS を使うにしても、世界中から見えるところではなく内部ネットワークからのみ参照できる DNS に登録しても自分たちの管理上は何ら問題ない。わざわざ外から見える DNS に逆引きを登録するのは、そうしないとアクセスを蹴るやっかいな人たちがいるから、という以上の理由はない。ログに逆引きホスト名で記録されてるとわかりやすいかもしれないけど、それは自分が逆引きする理由になっても、他人に逆引き登録を強要する理由にはならない。
_ いちおう念のため書いておくと、v6 では逆引きを登録するべきでない、といってるわけではない。v4 と同じように頑張って登録するのを否定するつもりはまったくない。やるのであればちゃんと正逆一致するように、そして、登録しないという選択肢もあるんだから逆引きが存在するのを前提とした設計にするのはやめよう、ということ。少なくとも、v6 に関しては「逆引きを設定しないのは管理がなってない」と断ずるのは間違いである、それを根拠にメールの spam 判定はできない、ということは覚えておいてほしい。
_ この前意図的に無視した資料を参考までに。v6 アドレスを配る ISP は逆引きをどうすればいいかについて書かれた Reverse DNS in IPv6 for Internet Service Providersというドラフト。割り当てする立場で書かれたもので、割り当てを受けたユーザがどういう方針で逆引きを設定すべきか、ではないこと、また、議論中のドラフトであって RFC ではなく、仮に将来 RFC になっても informational で何の強制力も持たないことにまず注意。この中では、NXDOMAIN を返す、ワイルドカードを使う、DDNS でユーザ自身に更新させる、ユーザに委譲する、 動的に生成するの5案が提示されていて、委譲 -> DDNS -> 動的生成の順で望ましい、としている。この推奨順は最新版ドラフトではじめて入ったもので、 初版の推奨は逆引きなしだった。いろんな意見があって決着がついてないことがうかがえる。個人的には、委譲はともかく DDNS や動的生成をしてまで逆引きを解決できるようにするぐらいなら NXDOMAIN でいいと思う。
_ ボス以下自転車乗りがたくさんいる職場はダメだ。自転車操業たのしいよね、とか平気で口走りやがる。
_ DNSSEC について頼まれものの作文を書いてたり。あたりさわりなさすぎて、われながらつまらない内容になってしまったと思うが、まあ気にしないことにする。
_ で、これを書くにあたり DNSSEC の背景をあらためて調べてたんだけど、うーん。どこの解説文書を見ても、素の DNS は毒入れできちゃう穴があるよ、だから対策が必要だよ、としか書いてない。こういう書き方だと、その穴をふさぐため「だけ」の技術だと勘違いしないかしら。というか、そう勘違いしている人の方が多いんじゃないかしら。そうじゃないんだけど。その穴を利用しない方法による毒入れだってある。そいつらまでぜんぶひっくるめて DNS の応答を改竄できないようにしてやろう、というのが正しいんだけど、そう読み取れる解説ってほとんど見当たらない。まあ、わしの作文もそんなふうにはとても読めない記述なんだけど。
_ 偽造パケットを投げて毒入れできちゃう、という穴をふさぎたいだけならば UDP ではなく TCP を使えばいいし、UDP でも source port randomization や 0x20 bit encoding といったテクニックで成功確率を大きく下げられる(ゼロにはならないけど)。これは DNSSEC を批判している人が主張しているとおりで、そのことにまったく異論はない。しかし、そういう方法を使えばいいじゃん、というのは、DNS 以外は信頼できる、というのが前提になる。信頼できるの？ ほんとに？
_ 悪意ある第三者が経路上のルータか何かでパケットを書き換えたり、何年か前にさくらインターネットであった ARP ポイズニングでサーバの IP アドレスを完全に乗っ取ったりといった、通信経路を乗っ取るような攻撃がなされると、DNS 自体の脆弱性に頼らずとも毒入れが可能になる。もちろんこれは DNS にかぎったことでなく、それに対する特別な防御を持たない TCP/IP 上のほとんどのプロトコルも同様に危険にさらされる。DNS のしょぼいところはこういう経路乗っ取りのような下のレイヤに対する攻撃をするまでもなく、あさってのところから攻撃できてしまうとんでもない穴があることで、そのためそれが主に解説されるけど、DNSSEC は別にその穴だけを対策してるわけではない。このような下のレイヤが攻撃された場合であっても耐えられるようにする拡張である。一方、TCP や port randomization で対策できるのは DNS 自身の穴だけで、DNS の範疇外でおこなわれる攻撃にはまったく役に立たない。
_ DNS の守備範囲外でおこなわれる攻撃にまで DNS が責任を持つ必要はない、という考えもあるかもしれない。でも、それをいったら HTTPS も SSH もいらない理屈になる。HTTP で十分。telnet で困らない。別に HTTP や telnet 自身に穴があるわけじゃないんだから、下のレイヤが信頼できて盗聴・改竄されない保証があるならそんなものを使う必要はない。ところがそんなのまったくあてにできないから独自に守りを固めてるわけ。DNSSEC もそれとまったく同じこと。DNSCurve もきっと同じ考えのはず(そうでなければ djb は「djbdns は port randomization をやってるから問題ない」と言えばいいだけで、わざわざ DNSCurve なんてものを提案する理由がないし、実際 DNSCurve は下のレイヤへの攻撃にも耐えられる設計になっている)。
_ 逆に言えば、すべての web サイトが HTTPS を必要とするわけではないのと同じように、すべてのドメインが DNSSEC や DNSCurve を必要とするわけでないともいえる(いまどき telnet がありえないのと同じように素の DNS もありえない、という考え方もできる)。個人的には、port randomization では毒入れの確率をゼロにはできないけど、それでも実用にはほぼ問題ない程度まで確率を下げられるので、安全性にそれほど気を使わなくてもいいドメインにまで無理に導入する必要はないと思ってる。ただ、だからといってすべて不要というのは暴論。
_ まとめ。DNSSEC は(そしてたぶん DNSCurve も) DNS の脆弱性をふさぐため「だけ」の技術じゃありません。従来知られていた穴を利用した以外の方法による毒入れも防ごうとする試みです。一方、TCP や port randomization はその穴からの攻撃を防ぐことだけしかできません。それだけやっとけば問題ないと言ってる人がいれば疑っておきましょう(用途によってはほんとにその程度で十分なこともあるので、それだけで嘘つき呼ばわりしちゃいけません)。