_ DNS で ANY を聞くとだぁーっといっぱい答が返ってくるわけだけど、そもそもふつーに使ってて ANY を聞くことなんかあるんですかね。人間がテスト目的で手で叩く以外で。qmail は MX を聞くかわりに ANY を聞くけど、それぐらい？
_ それから、UDP 512バイトの壁を越えるためには EDNS0 を使うという方法があるけど、キャッシュサーバではないふつーのクライアントから EDNS0 なクエリがやってくることってあるんですかね。NetBSD、OpenBSD は resolv.conf の options edns0 で設定できるけど、それぐらい？
_ で、さらに、ANY かつ EDNS0 なまっとうな問い合わせって、どんだけあるんですかね。まずないよね、きっと。かぎりなくゼロなんじゃないかな。
_ というわけで、そういうクライアントがもし存在していたら申し訳ないけどちょっとだけ苦労してもらう unbound のパッチ。
_ 何をするかというと、ANY が聞かれたら EDNS0 が有効でも無視して512バイト以上で TCP にフォールバックさせる。ANY でなかったり、ANY でも512バイト以内に収まるならふつーに UDP で完了するし、TCP なら大きなサイズでもちゃんと答えるので、問題になることはまずないはず。
_ さらに、とくに狙われやすい . と isc.org については、EDNS を使っていなくても
という「TCP で聞き直せ(tc)」というだけの極めて小さな応答(応答サイズが問い合わせと同じで増幅率1倍)を返す。どの名前を対象にするかは設定でいじれるようにした方がいいんだろうけど、めんどくさいのでハードコーディング。> dig @localhost isc.org any +ignore ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42375 ;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ... ;; MSG SIZE rcvd: 25_ TCP での問い合わせならふつーに答えるので、まっとうなクライアントはちゃんと名前解決できるはず(効率は落ちるけど)。家庭用ルータの内蔵 DNS フォワーダは TCP に対応してないものが少なくないけど、そういうものはたいてい EDNS0 にも対応してないのでどっちにしろ名前解決できないということには変わらないし、そもそも ANY を聞くことがないのであればパッチの有無は関係ない。ちうことで、事情があって acl を広く開けとかなきゃいけないホストだったとしても DNS amp の踏み台にされたときの攻撃力をだいぶ軽減することができる。minimal-responses: yes も設定しておくとなおよし。いちおう ANY だけに限定してるけど、を使わなくても RRSIG とか NXDOMAIN + NSEC3 とか大きな応答はいろいろパターンがありうるので条件を削ってもいいかも。
_ BIND の場合は、max-udp-size 512; と設定すれば、EDNS0 な問い合わせでもかならず512バイト以下で答えるようになるので(そのはずだけど確認はしてない。edns-udp-size は関係ない)、とくに改造する必要はないけど、ANY 以外でも応答が大きければ TCP にフォールバックしまくるので、DNSSEC まわりでちょっとアレかも。
_ こんなの。
へー。Apple が Microsoft 製品でメールを送るんだ。ふーん。Received: from rd.vesystems.biz ([127.0.0.1]) by rd.vesystems.biz with Microsoft SMTPSVC(7.5.7601.17514); Tue, 16 Apr 2013 06:41:45 -0700 Subject: Please confirm your information From: "Apple" <service@apple.com>_ マルチパートの text/html の方はフィッシングサイトに誘導してるけど、text/plain の方はちゃんと www.apple.com にログインしてくれ！と書いてあるのがなかなか興味深い。
_ HTTP/2.0 のドラフトを斜め読み。
_ …うーん。
_ SPDY がベースになってる(そもそも 初版はタイトルが HTTP/2.0 じゃなくて SPDY だった)のは、聞いてたからまあいいんだけど、これを HTTP と呼ぶのは抵抗があるなぁ。TCP の上に別途トランスポート層(あるいは OSI 階層モデルでいうセッション層)を定義する話が主であって、さらにその上でアプリケーション層としての HTTP メッセージをやりとりする話がほとんどない。両者を HTTP/2.0 としてひとつのプロトコルにまとめるのはかなり無理があるような。新しいセッション層のプロトコルと、その上にかぶせるアプリケーション層と2つのプロトコルに分離するべきなんじゃ。そうすればその新しいセッション層の上で HTTP 以外の別のアプリケーションを動かせるかもしれないし。
_ …まあ、そういう階層構造にすると効率下がるからくっつける、と明記されてたりもするんだが(5.1節)。
_ ほとんど白紙も同然のアプリケーション層のリクエスト/レスポンスのやりとりについては、HTTP/1.1 のような Header: じゃなくて :header: になったよ、とかサーバからの push 通知ができるよ、とかそのぐらい。具体的な内容についてはまったく書いてない。ほかの部分も流動的なところが多そうなんで、実際に仕様が固まるのは1年や2年じゃ無理だな。5年かかっても驚かない。
_ TLS 必須という噂もあったので警戒してたけど、とりあえず TLS なしでもいけるように読みとれる。後段の負荷を減らすためにリバースプロクシで HTTPS -> HTTP に変換する、なんてふつーにおこなわれていることが HTTP/2.0 になったらできなくなった、とかいうアホな事態は避けられそうだ。ただ、6.2 節に「TLS を使うことで新しい cross-proctocol attack はなくなるよ」とか書いてあって、やっぱり TLS 以外で使う考慮はあまりされていないように感じる。まあ、この部分には Issue: This is no longer true と注釈入ってるんで、そのうち書き換えられるだろうけど。
_ まあ、SSL なしの平文 HTTP/2.0 なんてのを 80/tcp に流すと各所でトラブル出まくりなのは確定なんだが。http を解釈するのはサーバとブラウザだけでなくて、透過プロクシとか Web アプリケーションファイアウォールとか、経路上のネットワーク機器なんかにもいろいろあるわけだ。でも、どの HTTP バージョンを使うかはサーバとブラウザの間のネゴで決まってこれらの機器は介入できないし、ブラウザが進化するほどには機器の更新は進まない。既存の HTTP/1.x しか解しないこれらの機器が同じポート番号で謎の新プロトコルを扱えなくて HTTP/2.0 にしたらうまく通信できないという悲鳴が各所で上がる未来が見えるよ。ドラフトからは 80/tcp はそのままでいきたい、URL のスキームは http:// のままでいきたい、という意図は感じるんだけど、まあそんなわけで http2:// なり spdy:// なりにして別ポートで動かすようにしないと難しいと思うな。HTTPS なら暗号化されててそういう機器は介入できないから関係ないが。
_ あと、このドラフトが参照してるリファレンスで、HTTP/2.0 ではなく 1.1 の方も改訂作業が進められていることを初めて知った。けっこう前からやってたみたいだね。仕様が巨大すぎて6分割されとる。いまはとても読む気にはならないけど、タイトルだけを見た感じだと Part 1と Part 2だけ読んでおけばとりあえずはなんとかなりそう。
_ こんな感じで。
8.8.8.8 に akamai な名前を聞いて、その結果返された IP アドレスへの RTT が 15ms 以下に。% dig @8.8.8.8 www.asahi.com +short www.asahi.com.edgesuite.net. a1403.b.akamai.net. 117.104.139.188 117.104.139.189 % ping -c5 117.104.139.188 PING 117.104.139.188 (117.104.139.188): 56 data bytes 64 bytes from 117.104.139.188: icmp_seq=0 ttl=52 time=12.685 ms 64 bytes from 117.104.139.188: icmp_seq=1 ttl=52 time=11.681 ms 64 bytes from 117.104.139.188: icmp_seq=2 ttl=52 time=11.904 ms 64 bytes from 117.104.139.188: icmp_seq=3 ttl=52 time=14.001 ms 64 bytes from 117.104.139.188: icmp_seq=4 ttl=52 time=11.837 ms --- 117.104.139.188 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 11.681/12.422/14.001/0.863 ms_ 1年半前の観測結果だと、同じことをやっても 100ms 以上かかっていたが、いまは近所につながるようだ。 このへんも参照。つまり、8.8.8.8 自体は日本国内にあるようだが、それは forwarder でしかなく、実際に名前解決をおこなっているサーバは国外にあって、そのせいで akamai なおの CDN サービスは遠いところに誘導されるんだろう、という構成だと思われていた。が、どうやら名前解決をおこなうサーバも国内に設置されたっぽい。
_ 数日前に 8.8.8.8 自体への RTT が 50ms ぐらいかかるようになったという話をちらっと聞いて、でも今日には 10ms 以内で応答するように戻っていた。これから推測されるのはメンテのため(?)に一時的に anycast の向け替えをやったんだろう、ということ。さて、じゃあいったい何のメンテをしたんだろう、と考えて、もしやと試してみたらこの結果だった。つまり、8.8.8.8 で動いている forwarder の向け先を国外サーバから日本国内に切り替えるメンテだったのではないかという想像。といっても、数日おきに定点観測しているわけでもなく、推測を裏付ける証拠もなく、実際にいつからこのように速くなっていたのかは不明で、もしかしたらずっと前から akamai も速くなっていたのかもしれないけれど。ただ、 このへんを見るに、少なくとも今年の2月までは遅かったようだ。
_ まあそんなわけで、今では google public dns の速度的なデメリットはほぼなくなった、といっていいみたい。