MoinQ: DNS/beyondDNS/2011-05-17

DNS/beyondDNS/2011-05-17について、ここに記述してください。

beyondDNSはDNSに関しての誤解をすこしでも減らすためのtweetです。皆さんのまわりにも広めてください。(拡散希望） Tue May 17 00:22:00 +0000 2011
@tss_ontap_o ありがとう。こちらのリスト（掲載分の親）にもありました。 他にもあるかもしれない。 Mon May 16 05:19:20 +0000 2011
DNS/キャッシュサーバ/IPアドレス ; google キャッシュらしきもののリスト Mon May 16 04:26:57 +0000 2011
wiki に作成中です：コメントしてください。 DNS/キャッシュサーバへの毒盛/攻撃 Sun May 15 11:44:27 +0000 2011
moin.qmail.jp の A レコードをキャッシュしているサーバに毒をいれて、本来のサイトではないIPアドレスへ誘導する方法を説明する予定ですが、twitter では長くなり不便 なので、wiki に書くことにしました。 進捗状況はtwitterに適宜報告します。 Sun May 15 10:53:25 +0000 2011
http://dnsdoc.qmail.jp/rfc1034/chapter3.html#04 (復習のためにRFC1034の拙訳へのリンク） DNS query/response のフォーマット、4つのsection など。 Sun May 15 10:49:32 +0000 2011
http://www.jhsoft.com/dns-xqid.htm Anti DNS spoofing - Extended Query ID (XQID) --- proposal now retracted 政治的問題にいやけ？ Sun May 15 10:41:01 +0000 2011
ISPの共用キャッシュサーバはISP契約していれば、... なので、危険です。一番の解決は自前のローカルキャッシュでしょう。 Sun May 15 10:13:13 +0000 2011
公開キャッシュサーバはDNS query を外部からコントロールされるので、危険だといえます。アクセス制限されていれば、ちょっとだけ安全かもしれないけど。 Sun May 15 10:11:51 +0000 2011
DNS-OARCのテストとはport randomization を調べてくれるサイトを使ったテストです。ここでgoodでも 安心してはいけない。poor は大問題です。 Sun May 15 10:09:59 +0000 2011
キャッシュ毒盛のための攻撃を可能にするための条件を書いてきましたが、お分かりいただけたでしょうか。返事をください。 返事の数によって、今後の方向を決めたいと思います。(ここまでついてきている人は約３名、悲しい現状です。） Sun May 15 09:51:44 +0000 2011
sphere の DNS管理はかなり低レベルです。しかし、脱出するのも大変です。 Sun May 15 09:19:46 +0000 2011
@bosturbo BINDギルドが宣伝していたことのひどさを証明する証拠がなかったのです。DNSSECの宣伝に使われているという心配はしていました。 Sun May 15 08:11:19 +0000 2011
@bosturbo ISPのキャッシュサーバというのは客でないと分からないので調査していませんが、ISPの提供するコンテンツサーバがキャッシュ兼用になっているのは結構あって、ひどい状態でした。多少改善されていますが。 ひどいキャッシュサーバのリストを作りませんか。 Sun May 15 08:08:51 +0000 2011
@bosturbo 当時、djbdns, unbound には脆弱性はない。と書かれていたが、それは嘘です。BINDのような脆弱性がないだけ。 Sun May 15 07:37:59 +0000 2011
DNSCurve はまだ案もなかったはず。DNSSECはまだ実用的ではなかった。 すぐに移行できる状態でDNSSEC移行を宣伝していれば、のせられた人は出たでしょうけど、幸いでした。 Sun May 15 07:35:37 +0000 2011
@bosturbo 毒の入りにくい挙動のテストというのはおそらくport 固定かどうかというテストではないですか。あれなら誰でもできますね。それで結果によってちゃんと対応したかどうかが問題です。 Sun May 15 07:10:16 +0000 2011
IPv6でのDNSqueryの送信アドレスはどうなっているのでしょう。ランダムに設定できるbitが多数ありそうですが。 Sun May 15 04:48:05 +0000 2011
@suu_g ありがとう。影響の大きさを考えると、24では足りませんね。やってなければ、ということは考えたくないが。:-< Sun May 15 04:45:41 +0000 2011
clworld の「難しいのはDNSだよ」は意外に事実かも知れないなと、反省している。 DNSSECについては必要性を感じていないから、まじめに学習していないけど。 Sun May 15 03:21:22 +0000 2011
@tss_ontap_o BINDのbugを解説してください。（検証できるくらいに） Sun May 15 02:18:02 +0000 2011
@suu_g google は複数の問い合わせアドレスを使っているそうなので、まったく無駄ということでもない。方向はOK。もっといろいろ工夫はできそうなので、考えるのは悪くない。 Sun May 15 02:16:52 +0000 2011
@tss_ontap_o google のIPアドレスがどれくらいランダムかどうか調べられますか。（予測可能か）奥村さんに相談？ Sun May 15 02:14:39 +0000 2011
@bosturbo DNSSECを進めるのを遅くするので、排除されたのではないかと 推測します。排他的ではないのに。 Sun May 15 00:22:33 +0000 2011
@bosturbo firewall屋さんがいやがりそう、なんてのは誤解でしょう。彼らはセキュリティを考えているはずで、壁を作ることを目的にしているのではない。（はず） Sun May 15 00:20:54 +0000 2011
@bosturbo 返事ありがとうございます。 分かっている人に通じたという程度の書き方だと反省しています。 実装を確認した人が多かったという根拠を教えていただけますか。 Sat May 14 22:31:52 +0000 2011
@wintry_scene 返事ありがとう。なんとなくわかった、というのでも読んでいる人がいるとわかってうれしいです。 でも、わかっていないことは確かです。 読み直して、分からない部分は本当の先生に質問してください。 Sat May 14 22:22:38 +0000 2011
ISPの共用キャッシュサーバもそういう対策をしてくれるといい。IPアドレスはたくさん持っているだろうから。 Sat May 14 22:17:37 +0000 2011
googleやOpenDNSのような共用キャッシュサーバでは問い合わせに使うIPアドレスもたくさんの集合からランダムに選んで いるのかもしれません。(知りません） 多少は防御を強化できるでしょう。 Sat May 14 22:15:51 +0000 2011
@suu_g 結論は対策にならない、です。 関係を発見することはやさしいだろうから。 （beyondDNS向けに書いてもらえば、すぐに返事できたと思う。） Sat May 14 15:34:03 +0000 2011
キャッシュ毒盛のための攻撃を可能にするための条件を書いてきましたが、お分かりいただけたでしょうか。返事をください。 返事の数によって、今後の方向を決めたいと思います。studyに参加している方はあちらで返事してもらってもかまいません。質問も歓迎します。 Sat May 14 15:27:24 +0000 2011
transaction ID を32ビットか64ビットに拡張するだけで、暴力的攻撃から守ることができる。BINDの影響力からすれば、そんな実装は簡単だったろうに、なぜやらなかったか。なぜ、DNSSECに走ったのか。 Sat May 14 13:46:55 +0000 2011
http://blog.ohgaki.net/binda_rdnsa_sa_pa_a_ma_yap_a BIND9のDNSキャッシュ汚染 Sat May 14 12:28:23 +0000 2011
http://www.securityfocus.com/bid/30131 Multiple Vendor DNS Protocol Insufficient Transaction ID Randomization DNS Spoofing Vulnerability Sat May 14 12:26:25 +0000 2011
UDP transaction ID のことを言及するのを忘れていました。 Sat May 14 12:25:50 +0000 2011
http://is.gd/eiycn5 Harden BIND9 Against Cache Poisoning Sat May 14 12:23:35 +0000 2011
TCPなんて使えん、という人にはDNSCurveを検討することを勧める。 Sat May 14 07:44:50 +0000 2011
明日以降の話題の予告：形式的には返答だが、DNS返答としては怪しいということでキャッシュしないという対策などを書く。 Sat May 14 07:42:14 +0000 2011
毒入りの返答を形式的に判別する方法はここまでです。前野の知識もここまで。 なぜ、UDPにこだわるのか、という疑問に行ってしまって、これ以上考えたくないということかもしれません。 Sat May 14 07:38:59 +0000 2011
問い合わせたいtypeによっては、query name にノイズを加えることも可能になります。これは後半の防御法に含まれます。 Sat May 14 03:27:41 +0000 2011
この方法を使うと、長い名前の方が防御に有利ということが言えるでしょう。 Sat May 14 03:25:51 +0000 2011
毒入れ防御のつづき：queryとresponseに現れるquery name は同一でなければならないということとドメイン名は大文字小文字の区別がないということを利用して、ほんの少しノイズを入れられます。unboundでは使えるはずです。 Sat May 14 03:24:44 +0000 2011
dnssec 推進協賛の組織にいても、dnssecに疑問を抱いている人は相当いるはずです。立場上発言できないとしたら、なにか 別の手段で表現できませんか。孤立状態で 悩んでもプラスにはならないでしょう。 できる協力はします。応援もします。 Fri May 13 23:55:01 +0000 2011
http://t.co/S7kjGWI ネット接続を遮断する「ブロッキング」、対象外のサイトまで閲覧不能に、ぷらら Fri May 13 22:28:56 +0000 2011
port番号を可変にする以外の対策もありますが、つづきは明日以降にします。調べてみるとおもしろいでしょう。ヒントはunboundにあります。 Fri May 13 13:10:06 +0000 2011
DJB提案により、毒盛には（計算上は）2**16倍の偽返答を送りつける必要生じたのですが、Kaminskyの発見まではBINDユーザには広く知られていなかったようです。 Fri May 13 13:08:14 +0000 2011
そういう歴史から、queryを推測することは簡単だということはよく知られていました。そこで、DJBは16ビットあるport番号をrandomに使うことを提案して、dnscacheで実装しました。（1999年ころ） Fri May 13 13:04:15 +0000 2011
response のheader部分はqueryと整合していなければならないとされています。 送信IPアドレスや受信IPアドレス+portは簡単に求められます。BINDの場合、送信ポートが固定だったり、固定設定されていたり、少数からの選択だったりしました。 Fri May 13 12:59:19 +0000 2011
response(返答）の項目にはqueryの項目に加えて、3つのsection(レコードセットからなる）からなる返答があります。 Fri May 13 12:55:46 +0000 2011
queryとresponseのフォーマットについてはRFCを見てください。query の項目としては 送信（IPアドレス、port）、受信( IPアドレス、port), query (name, type) ... などがあります。 Fri May 13 12:53:02 +0000 2011
公開キャッシュサーバが特に危険といわれるのは、query を攻撃者が完全に予測できる（可能性がある）からです。 Fri May 13 12:47:48 +0000 2011
つまり、攻撃のためには、ターゲットが送り出すqueryとそれに対するサーバからの返答を予測する必要があるとします。 Fri May 13 12:45:36 +0000 2011
前提条件として、攻撃者はターゲットのquery packet を見ることはできないものとします。（攻撃者は同一のネットワークな どにはいない。） Fri May 13 12:44:03 +0000 2011
キャッシュ毒盛を防ぐには： DNSSECではない手法を 二つに分けて簡単に書いてみます。 (1)偽返答を判別しやすくする (2)偽返答をキャッシュしにくくする （つづく） Fri May 13 12:42:10 +0000 2011
DNSSECの普及度をみるために、DSレコードの登録数を数えています。 wiki: DNS/DNSSEC/DS Fri May 13 12:30:54 +0000 2011
しかし、DNSサービスに関しては海外のDNSホスティング業者のことは考慮しないでいいのだろうか。 Fri May 13 09:44:44 +0000 2011
ただし、当分はDNSSECの必要性はないと考えていれば、あわてることはない、という立場もありえる。 Fri May 13 08:37:15 +0000 2011
DNSSEC推進側としてはDNSは崩壊してもDNSSECが残ればいい。DNSSECは自分たち業者が面倒みるから。という考えだと受け取れるが、DNSが崩壊してもDNSSECは残るのだろうか。DNSすら維持できないのにDNSSECが... Fri May 13 08:35:45 +0000 2011
mahbo さん流に言えば、DNSSECの必要性が低いことを示しながら、DNSの重要性を訴えるということになります。 Fri May 13 08:21:20 +0000 2011
まともな管理者はDNSSECにはかかわらない、ということを期待しましょう。そして、我々はまともな管理者を増やすにはどうすべきかを考えましょう。 Fri May 13 04:56:46 +0000 2011
ただでも足りないDNSを理解した技術者をDNSSECの実装と運用にとられて、非DNSSECの運用は大丈夫か、ということですね。 Fri May 13 04:54:45 +0000 2011
EDNS0というのは末端だけで実装すればいいというものでしょうか。DNSSECに対応するには必須だと思っていますが。 Fri May 13 04:46:19 +0000 2011
おかしな推進だという理由のひとつが、「非協力的な運用者」を前提にした移転のガイドです。DNS浸透問題をご存知ないらしい。 Fri May 13 00:03:02 +0000 2011
（DNSSECの運用が困難＝DNSSECを否定）ではないと思う。DNSSECを肯定はしないが。現状はDNSSEC推進の根拠がおかしい、と述べている。おかしい根拠の推進には否定的だということ。 Fri May 13 00:00:20 +0000 2011
非公開でも心配で発言できないのなら、 DMでどうぞ。勉強会の方は参加者をフォローしています。 Thu May 12 23:33:48 +0000 2011
@mahbo インターネット全体へのDNSSECの普及は一部の人間がやればすむことだとは考えませんので、まったく 同意できません。（ご意見は理解したと思います。） Thu May 12 12:37:58 +0000 2011
@mahbo 書かれていることはごもっともですが、私が言っていることではありません。「解釈」が間違っているのでしょう。他人が論理的でないと攻撃するのであれば、まず自分の発言を見直すべきです。 Thu May 12 12:35:22 +0000 2011
DNSSECを推進している組織に「まともな管理者を育てよ」とは言っていません。 世間一般に対する要請だと受け取って欲しい。限定するとしても、DNSホスティングを商売にしているようなところに対しての要請だと思ってほしい。 Thu May 12 05:22:08 +0000 2011
@mahbo 解釈を引用のように書かれては他の方の誤解を招くので、お控えください。それで、まともなDNS管理者を育てる必要はない、という解釈でよろしいでしょうか。 Thu May 12 05:16:00 +0000 2011
@mahbo 具体例を書いていただければ、イメージできるかもしれませんが、 いまの説明ではまだ理解できません。 DNSの運用と個々のネームサーバの運用を区別された理由を説明していただくのがいいかもしれません。 Thu May 12 05:13:50 +0000 2011
@mahbo　「DNSSEC普及の前にDNS管理者を」の出所を教えてください。 Thu May 12 04:53:23 +0000 2011
@mahbo つぎの文にある、DNSSECの運用、DNSの運用、個々のネームサーバの運用をどう区別しておられるのか説明してください。 Thu May 12 04:51:04 +0000 2011
@mahbo 意味がとれませんので、一文ずつ説明をお願いします。こちらの解釈を書きますので。 DNSSECは使いたいものが使えばよい。 ([必要に応じて]、というのをそう理解していいですか。）[普及すれば良い]は願望ですね。 Thu May 12 03:59:43 +0000 2011
dnssec.jp 協賛組織の中の人とか、表だってはDNSSECに疑問をはさめない人も おられるでしょう。study_dnsに入って、本音で議論しませんか。一応非公開tweetです。ROMはお断りです。 Thu May 12 02:13:32 +0000 2011
. @mahbo 大変ですね。どうやって普及させるのでしょう。毒入れの恐怖ですか。もっと怖いものがDNSの世界にはあると思いますよ。まともなDNS管理者を 育てないと話になりません。 Thu May 12 01:21:59 +0000 2011
少ない数ですむのはキャッシュが使う問い合わせのport番号が53に固定されていたり、少数のport番号に制限されていたりしたからです。 Wed May 11 22:29:07 +0000 2011
キャッシュ毒盛は偽返答をうんとたくさん送りつけ、どれかひとつでも受け取ってくれれば攻撃成功という野蛮な方法です。BINDで問題となったのは、djbdnsやunboundに比べて、はるかに少ない数の偽装返答を送るだけで成功することが示されたからです。 Wed May 11 22:27:21 +0000 2011
Kaminskyのスライドの通りで毒入れできたとか、ちょっとした変更で毒入れできたと言う話を聞きます。unboundではなく、BINDのようです。djbdns相手の話はまたの機会に。 Wed May 11 21:07:39 +0000 2011
. @yutapon Kaminsky のスライドの間違いにBIND関係者が気づかないはずはないので、なぜずっと放置されていたのか、という疑問がありました。BINDに不良があったからだ、と解釈するのが素直です。 Wed May 11 20:55:36 +0000 2011
JPサーバに登録しているサーバが確認できましたか。できたら、登録サーバに問い合わせてみて、同じサーバ群が返ってくるか、調べましょう。違っていたら、問題が あるかもしれません。なぜ？ Wed May 11 14:15:39 +0000 2011
@yutapon はい。私もそう判断します。メリットが大きいと思えるところだけが やればよろしい。 Wed May 11 14:11:03 +0000 2011
. @yutapon しかし、別の攻略法があって、（こちらはDNSの構造と関係しています）それと組み合わせると毒入れできると言えます。防御ができないものではありませんが。 Wed May 11 14:08:18 +0000 2011
. @yutapon 元々TTLの制約というのが成立していなかったと考えます。Kaminsky が説明したままでは毒入れは できなかったはずなので、BINDの不良が関係していたという推測ができます。 Wed May 11 14:05:15 +0000 2011
どういう情報が登録されているかは省略します。ここでの問題は委譲(delegation) です。所有するドメインのDNSサーバを JPサーバに登録してあるか、確認してみましょう。 Wed May 11 13:23:19 +0000 2011
DNSは階層構造をしています。JPドメインの根は[a-g].dns.jpという名前のサーバです。多くのJPドメインはこれらのサーバに 登録されています。 Wed May 11 13:20:58 +0000 2011
キャッシュ毒盛はひとまず終わったことにして、新しい話題に移ります。 DNSコンテンツサーバの設定間違いとか、 管理不良を扱いましょう。 Wed May 11 13:18:19 +0000 2011
@sedawkperl はい。協力に感謝してい ます。勉強会は今なら、即時に入会可能です。:-) Wed May 11 06:20:47 +0000 2011
study_dnsでは、DNSSEC推進の根拠といわれるキャッシュ毒盛についてじっくり勉強していくつもりです。参加者の興味が続けば、という条件がつきますが。 Wed May 11 06:19:07 +0000 2011
twitter をつぶやきと日本語化したのは間違いだ。そういう間違いはよくあるが。 道具は使う人（人々）が工夫して使って始めていきるものであることを忘れてはならない。beyondDNSは酔っ払いのつぶやきではない。 Wed May 11 06:10:56 +0000 2011
@sedawkperl 楽しみ方はそれぞれ。私はメイリングリストと違うとは思っていない。電光ニュースと違って、消えてしまう訳ではないから。メイルはメイルで問題が大きくなったので、twitterを始めました。 Wed May 11 06:07:27 +0000 2011
返事をいただいた方へはお礼の意味で、 DNS勉強会に招待します。 study_dnsをフォローしてください。 一緒に勉強しましょう。 https://moin.qmail.jp/beyondDNSにも書いてあります。 Wed May 11 05:39:19 +0000 2011
学生への警告：beyondDNSは未成年者には毒になります。直ちに死ぬ訳ではないが、長いはずの人生を短くする可能性があるので、十分注意するように。大学での講義の代わりにはならないことも申し添える。（再録） Wed May 11 05:19:51 +0000 2011
興味をもたれた話題にはくだらない質問ではないかと迷うようなことでもどんでん質問していただいくようお願いします。つっこみも歓迎です。twitterでのやりとりを楽しんでみませんか。 Wed May 11 05:15:54 +0000 2011
返事のお願いの件は終了とします。14通の返事をいただきました。ありがとうございました。３回お願いしても返事をいただけない方は読んでいないものと考えることにします。現在、66アカウントからフォローされていることも合わせて報告しておきます。 Wed May 11 05:12:23 +0000 2011
twitter なんて見ただけで勉強になると思ってはだめですよ（特に学生は）。アホな質問でもしないと進歩しないと思うべき。 ここは分かったつもりの人を気づかせるための場だと思っています。遠慮なく書いて いいんですよ。 Wed May 11 01:26:00 +0000 2011
@ten_ten_Ash 楽しんでもらっちゃ困るんですよ。怒ってください。それがお布施です。 Wed May 11 00:15:58 +0000 2011
DNSSECはDNSとは別の世界で展開したらいいんじゃないかな。みんな幸せ。 Wed May 11 00:13:57 +0000 2011
qmail.jpはDNSCurveを使っています。コンテンツサーバはCurveDNS (proxy)です。NSレコードを見てもらえば分かります。キャッシュはdnscache + Dempsky patch です。 https://moin.qmail.jp/DNSCurve Tue May 10 22:52:20 +0000 2011
夜間に６名増えて、現在１２名の方から、読んでいるという連絡をいただきました。今日の昼すぎでひとまず打ち切りにします。 --- 読んでいるということだけでもうれしいのですが、もう一言あると、もっとうれしい。よろしく。 --- Tue May 10 22:40:37 +0000 2011
毒入れし放題のDNS(DNSSEC推進の理由）からDNSSECのような複雑な世界へどうやったら移行できるのか、示してもらいたい。 いまでも、ネットは運用や人の教育を軽視してよい実験の場だと思っていないか。 Tue May 10 22:23:28 +0000 2011
DNSSECでまともな運用ができるか：できると言うひとはDNSを理解していないと思ってよい。そんなものを推進する理由はなにか。よく考えてみよう。分からなければ、議論しよう。 Tue May 10 21:57:36 +0000 2011
@kogiso すぐには思い出せないのですみません。名古屋でお会いしているのでしょうね。よろしく。 Tue May 10 15:15:32 +0000 2011
@yutapon wiki は読んでいただいてますか。整理されていないので、申し訳ないのですが、コメントをいただけるとうれしいです。 Tue May 10 14:02:25 +0000 2011
@sakichan 名前が売りに出されているということですね。一括置換が手順として確立しているのだと、おもしろい世界です。日本でそういうことはできるところ（レジストラ）があるとは思えません。知らないだけでしょうけど。 Tue May 10 13:54:03 +0000 2011
@sakichan ありがとうございます。DNS設定そのものには問題はみつかりません。確かに、names-services.com 自身が売り物であるかのごときページはまずいというよりおもしろい。身売りされたら、どうなるんでしょうか。 Tue May 10 13:40:40 +0000 2011
@sakichan [自分で登録したドメイン]を教えていただけますか。調べてみます。 Tue May 10 13:23:44 +0000 2011
@sedawkperl 業者に委託するには業者に仕様書を作らせるようなことではだめですね。きちんと仕様書が作れるところまで到達していないと、委託もできない。と言う状況で行き詰まりです。 Tue May 10 13:10:07 +0000 2011
@sedawkperl 「自律は無理な規模か」の意味がとれません。何について言っていますか。 Tue May 10 13:07:21 +0000 2011
@sedawkperl ドメイン名の取得は安くて当然だと思います。問題は管理のコストです。区別しましょう。 Tue May 10 13:02:40 +0000 2011
いっそのこと、DNS管理は業者任せにすればいいという人もいる。（業者か代理人） でも、まかせられる業者は非常に高価らしい。ただし、高価だから大丈夫だとは限らない。本来、手間のかかる仕事だから、安い業者はどこかで手を抜いていると思うべきだ。さあ、どうするか。 Tue May 10 12:57:38 +0000 2011
DNSホスティング業者が安易で間違いを誘発するインターフェースを用意しているのも問題か。DNSの仕組みを理解せず、DNS RRの書き方(?)だけを真似て、設定したつもりになっている。（猿にタイプライタを渡すと、文学ができるという話を思い出した。） Tue May 10 12:54:06 +0000 2011
多くのひとにとってはDNSは存在すら気づいてもらえないものだが、一方で動作しないと困る重要なもののはずだ。だが、問題がおきてもひたすら回復を待つだけというような受身の姿勢しかとらない。なぜ、ちょっとでも勉強しないのか。（tss_ontap さんが出てくるかな。） Tue May 10 12:47:44 +0000 2011
twitterは夜に使われるという説もある。読んでいるという返事だけでもうれしいが、もう一言あると、もっとうれしい。よろしく。 Tue May 10 12:36:59 +0000 2011
そんなことまでして宣伝しなくとも、わかる人にはわかるソフトなんだが。　qmail だってそうなんだが、よってたかってパッチを作るから、誤解が重なって、本当の姿が見えなくなっている。 Tue May 10 12:35:14 +0000 2011
djbdnsの件はつりだったのか。 Tue May 10 12:31:09 +0000 2011
設定間違いを案内する無料セカンダリDNSサービス：http://www.maihama-net.com/dns_service.html　（ところで、なぜ無料で成立するのか、教えてください。） Tue May 10 11:10:38 +0000 2011
@akibaryu djbdnsすでに動いている！ Tue May 10 09:53:21 +0000 2011
@akibaryu Good Luck! Tue May 10 09:31:12 +0000 2011
@knobs @akibaryu 私もdjbdnsを勧めます。ただ、DNSのリスクは使うソフトよりも運用と運用者の知識によるので、 djbdnsを使ったから安心というものでは ありません。 Tue May 10 08:41:54 +0000 2011
@kjmkjm eclipse.org がしばらくアクセスできなくなっていたという話はご存知ですか。magmacom.com が失効したのが理由だそうです。 Tue May 10 07:38:13 +0000 2011
返信のお願いについての中間報告です。 現在、６名の方から返事をいただきました。 まだのかたはよろしくお願いします。 一日経ったら、終了ということにします。 Tue May 10 06:55:00 +0000 2011
検索の能率向上のためか、twitter負荷軽減になるのか、timelineに表示するのに便利という理由なのか、ハッシュタグを使うという方法もありました。いちいちタグをつけるのは面倒だと感じます。当面は@beyondDNSで検索してください。 Tue May 10 05:49:50 +0000 2011
このtweetを読んでいる人は返信してください。（ある種の実験です。協力をお願いします。） Tue May 10 04:53:33 +0000 2011
非公開アカウントで使っているgroup tweet 機能は参照が使えないようなので、 ごく少人数むけだと思います。議論するなら、twitter よりもメイリングリストかwikiの方が使いよい。 Tue May 10 04:18:06 +0000 2011
ある人から教わった方法を紹介します。beyondDNSで前野が返事したアカウントを含むリストを作っておきます。 余計なtweetを見ることになりそうなので、検索の方を勧めますが。いいとこどりの解決方法があったら教えてください。 Tue May 10 04:14:00 +0000 2011
@tss_ontap_o これまで他の人の発言はbeyondDNSのreplyでしか見ていなかったのか。想定外でした。そういう狭い見方しかしないとは。twitter をもっと活用していると思っていましたよ。 Tue May 10 03:55:35 +0000 2011
@sedawkperl 本人に尋ねてみたら。:-) Tue May 10 03:53:21 +0000 2011
@tss_ontap_o 方法としてはひとつの方法にすぎない。そういうことは考えたこともないが。twitter 検索を知らないようなので、beyondDNS で検索することを 試してみたら。 Tue May 10 03:52:33 +0000 2011
@tss_ontap_o はい。これでいいかな。 Tue May 10 03:43:20 +0000 2011
念のための警告：前野がりついーとしたものは反面教師としてのものが大部分ですから、疑問に思ったら、質問してください。 Tue May 10 03:13:01 +0000 2011
新規取得したドメインがキャッシュサーバに浸透する仕組みを知りたいとは思わないのだろうか。 Tue May 10 02:45:24 +0000 2011
ネットでの方向指示案内板であるDNS情報が消滅してもたいして困らない。eclipse.org事件で感じたことです。 Mon May 09 22:59:04 +0000 2011
@sedawkperl 想像をはるかに越えたものを認識できるとしたら、あちらの世界の人でしょう。現実には想定外のものは常にあるという謙虚さが必要ですね。数学のモデルはまた別の話ですが。 Mon May 09 14:13:44 +0000 2011
JPに登録されているものだけでも、こういう間違いがあるので、個々のDNSサーバが返す返事についてはもっとひどいと想像できるが、あまりまじめに調査をしたことはない。 Mon May 09 12:33:18 +0000 2011
ほとんど注意をひかないが、JPに登録されているホストのIPアドレスが間違っているものも多数ある。ホスト名よりIPアドレスの間違いの方が直接影響をうける。 DNSサーバの管理者は管理しているゾーン以外の名前の問い合わせがあることで気づいているはず。 Mon May 09 12:31:08 +0000 2011
放置されたドメインといっても、JPの下のものだけです。それ以外のものはしらんぷり。いつでも乗っ取れるドメインがごろごろ。犯罪になるので、乗っ取るだけの価値はないから、とられないですんでいると思いたい。 Mon May 09 12:28:08 +0000 2011
dnsops.jp は５年前にあったかな。あったかも。関係していないから、記憶の外です。 Mon May 09 12:12:26 +0000 2011
visa.co.jp事件のあと、JPRSなどはあわてて、放置されたドメインの整理に乗りだしました。（半年以上あとのことだった。） レジストリになにか期待するのは無駄だと思いました。 Mon May 09 12:10:10 +0000 2011
大げさに書くとvisa.co.jpドメインは一時tssさんの管理下にあった、となります。 Mon May 09 11:29:51 +0000 2011
visa.co.jp 事件についてはe-ontapに記事があります。http://is.gd/RboJhK 2005年にマスコミにも取り上げられたそうです。 Mon May 09 11:14:22 +0000 2011
@sedawkperl いつ知ったか、書いてないから、どれくらい前か分からない。 visa.co.jp事件発生は何年前か。それ以来 DNSの勉強をしていましたか。 まあ、これから勉強すればいいことです。 Mon May 09 11:01:40 +0000 2011
@sedawkperl eclipse.org 事件はおととい。興味をもつのはいいことだが遅すぎる。（年齢にもよるから一概に遅いとC決めつけるのはよくないが。） 反応してくれて、ありがとう。 Mon May 09 10:50:25 +0000 2011
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1060756605 堂々とした（おかしな）返事に感心してしまう。 Mon May 09 09:58:31 +0000 2011
いろいろでたらめ(都市伝説）を書いてみたのに、反応なしか。でたらめだとわからなかったのなら最悪の結果に。 Mon May 09 07:56:00 +0000 2011
推測ですが、DNSSECのモデルの中でDNSCurveを考えておられるようです。それでは理解できないと思います。 Mon May 09 03:47:06 +0000 2011
手元のサーバにDNSSECをインストールすることでキャッシュポイズニングの心配をしなくてすむ。というのがDNSSECを推進する人たちの宣伝文句。重大な落とし穴のことは小さく書いてあればマシな方だ。 Mon May 09 02:37:25 +0000 2011
ルートサーバとはDNSサーバネットワークの中心に位置するものである。浸透はいったんルートサーバに到達し、その後、すべての末端（？）サーバに到達する。これにより浸透が完了し、世界中の人から自分のウェブページ（HPとも言われる）にアクセスできる。（というイメージか。） Mon May 09 02:34:05 +0000 2011
DNSとはプロバイダの裏にあるDNSサーバのネットワークのことであり、プロバイダのウェッブインタフェースを使って書き込んだ情報が時間とともにネットワークに拡散していく。これを浸透という。というイメージらしい。クラウドもそういうものだと思われていたりしないか。 Mon May 09 02:29:55 +0000 2011
委譲とはwhoisデータベースに登録することです。というのは間違いです。でも、そう思っているDNSホスティングの客はたくさんいるでしょう。 Mon May 09 01:45:06 +0000 2011
eclipse.org は第二のvisa.co.jpになるか。 tss_ontap さんに期待が集まる。 Mon May 09 01:18:15 +0000 2011
@tss_ontap_o 自信(?)をもってDNS設定しているところほど危ない、ということもあるが。 Mon May 09 00:38:01 +0000 2011
http://www.computerworld.jp/topics/vs/118209.html　これを読み直してみると 当初どういう宣伝がなされていたか分かる。 Mon May 09 00:35:43 +0000 2011
eclipse.org の件はひとまず復活。 これも委譲の不良です。委譲先ドメイン喪失。 Sun May 08 23:28:45 +0000 2011
Kaminsky が異なる名前の問い合わせを送るというアイデアを思いついたときに、 委譲を使うことを想定していたことは確実ですが、委譲の弱点は彼の発見とは言えません。初期の報道は間違っていると考えます。 Sun May 08 22:45:48 +0000 2011
委譲は鎖のつなぎのようなものです。一番狙い易い弱点なので、毒盛の歴史によく登場しますから、調べてください。 Sun May 08 22:41:59 +0000 2011
そこで、DNSにおけるサブドメインの委譲(delegation)という弱点を利用します。 Sun May 08 22:39:47 +0000 2011
本当に毒盛したい名前(例えば、google.com)に毒を入れられなければ意味がありません。 Sun May 08 22:37:54 +0000 2011
しかし、キャッシュされていない名前に対して毒を入れられても、誰もそんなものを使わないので役に立ちません。 Sun May 08 22:36:04 +0000 2011
Kaminskyの手法の解説を続けます。彼の提案(あえて発見とはいわない）はキャッシュサーバにキャッシュされていない情報を問い合わせることで、毒盛の機会を増やすものです。 Sun May 08 22:30:43 +0000 2011
twitter profile が書き換えられていなければ、beyondDNSとmoin.qmail.jp管理者が同一だろうという推定が成り立つでしょう。 Sun May 08 13:40:08 +0000 2011
moin.qmail.jpのおれおれ証明が気持ち悪いという人がいたら、beyondDNS の twitter を見ろと言ってみてください。 Sun May 08 13:38:18 +0000 2011
SHA1 Fingerprint 58:EF:65:BC:D1:0D:C8:DC:49:04:F4:B7:B3:43:AF:12:53:2C:B6:F2 Sun May 08 13:11:30 +0000 2011
ドメインを個人で管理している方は一度試してみたらいかがでしょう。あまりの簡単さに感激することでしょう。(宣伝） Sun May 08 12:40:53 +0000 2011
DNSCurveではNSレコードに暗号化キーを含めますので、上位サーバに登録するNSレコードの追加変更作業が発生します。しかし、移転作業は通常のDNS移転と同じです。 Sun May 08 12:39:08 +0000 2011
DJBはTCPに代わるCurveCPというものを開発中ですが、よくしりません。 Sun May 08 12:36:00 +0000 2011
DNSCurveサーバの実装にはCurveDNSというプロクシサーバがあります。キャッシュサーバはdnscacheへのパッチが提供されています。 Sun May 08 12:34:43 +0000 2011
DNSCurveの紹介: https://moin.qmail.jp/DNSCurve DNSSECと違っているのは、 データではなく、DNS通信(UDP他)を (楕円曲線）暗号で保護しようというものです。DNSコンテンツサーバとキャッシュサーバ双方に実装します。 Sun May 08 12:32:23 +0000 2011
@tss_ontap_o そうですね。はやとちりだったかも。 Sun May 08 07:28:34 +0000 2011
おまけ：毒盛可能なDNSキャッシュにはBINDだけでなく、djbdns(dnscache)やunboundも含まれる。DNSSECが宣伝するところである。しかし、実用的には問題ない。 Sun May 08 02:40:54 +0000 2011
(まとめ）DNSキャッシュには毒盛の危険がある。これはKaminskyの指摘したことではない。最初から分かっていることである。Kaminskyはひとつの道具を提案した。 Sun May 08 02:32:39 +0000 2011
Kaminsky 講演のあとで、こうやれば毒が入ると解説しているページの説明を見れば、スライドとは違っていることが分かる。それぞれの説明の正しさは検証していないというか、検証できない。十分な情報がないから。 Sun May 08 02:30:04 +0000 2011
port randomization をしていないキャッシュサーバは論外としても共用のキャッシュサーバを提供しているISPは勉強不足 である。（ここではそう言っておく。） Sun May 08 02:27:34 +0000 2011
どの程度の危険であるかはキャッシュの実装、運用などによるので、ここでは省略する。 Sun May 08 02:24:56 +0000 2011
Kamisky が示唆した方法を用いてDNSキャッシュに毒盛できるということも事実である。BINDの不良によらなくとも可能で ある。ただし、適切な対策を施したキャッシュにとっては無視しうる程度の危険である。 Sun May 08 02:22:54 +0000 2011
Kaminsky 講演のスライド例に欠陥があることは事実である。これも分からない人は DNSキャッシュの仕組みを理解していないと思われるので、どこかで勉強すること。 Sun May 08 02:19:24 +0000 2011
. @tss_ontap_o あの方法というものを具体的に書いてください。Kaminsky 攻撃を解説したページには毒が入ったということがいくつも書いてあります。それとどう違うのか。さっぱり、わからない。 Sun May 08 02:08:26 +0000 2011
RT @tss_ontap T.Suzuki eclipse.org は その DNS を預かっている magmacom.com ドメインが期限切れのため、インターノットから消滅している。 Sat May 07 21:59:12 +0000 2011
@sedawkperl おもしろそう。ぜひ紹介してください。 Sat May 07 10:28:43 +0000 2011
@sedawkperl 急ぎませんので、必要性を展開してみてください。楽しみにしています。 Sat May 07 10:22:57 +0000 2011
@beyondDNS kaminsky の予告ではなく、BIND group への通告でした。修正します。 Sat May 07 10:10:14 +0000 2011
さて、これらの対策をすべて施してもまだ危険だというのがDNSSEC推進の理由とされているが、それは本当だろうか。かなり疑問だと考える。 Sat May 07 09:39:25 +0000 2011
一番大事なこと：偽の返答を送る前には問い合わせをさせなければならない。公開キャッシュサーバが危険である理由である。Kaminskyはほかの方法も示唆しているが、公開キャッシュほど簡単ではない。 Sat May 07 09:37:45 +0000 2011
もうひとつの対策： 偽返答を送る側にとっての問題は多数の偽返答を送りつける必要があることである。 送ってもいないDNS query に対しての返答が送られてきたら、警告をだすべきである。 Sat May 07 09:35:26 +0000 2011
偽返答を判別しやすくする方法は他にもあってunboundなどで実装されているが、ここでは省略する。 Sat May 07 09:31:39 +0000 2011
port randomization と言われているものはDJBがdjbdnsでとっくに採用しているものである。（2000年だったか） Sat May 07 09:29:15 +0000 2011
Kaminskyの予告から約半年たって公表された対策はport固定をやめるというものだった。なぜこれだけのことに半年もかけたのか。他の方法を探していたのだろう。 Sat May 07 09:28:02 +0000 2011
当時の警告はTTLを短くするのは危険というものだけだったと記憶している。 Sat May 07 09:22:51 +0000 2011
しかし、BINDキャッシュでは問い合わせportが固定されていることの方が深刻な問題であり、ずっと以前から指摘されていたにもかかわらず放置されていた。 Sat May 07 09:20:42 +0000 2011
Kaminskyの発見とは送りつけられた偽返答をキャッシュにあるデータにより防御するというBINDキャッシュなどのハックを回避 する方法の発見です。 Sat May 07 09:11:22 +0000 2011