tmux で、ステータス行にロードアベレージを表示させる

manにはsysctlを呼び出す方法が載っていますが、あいにくLinuxにはvm.loadavgというノードがありません。そこで、screenのように #L でロードアベレージを表示できるようパッチを書いてみました。
twitterにこんなことを書かれたので、Feature Requestしておきます。


送信ボタンを押した後に、 support-loadavg.patch にするつもりが support-loadavg.diff という名前にしていたことに気がつくというありがちなパターン。


追記:
rejectされました。unameを見るスクリプトよりも、十分ポータブルでコストも低そうなNickのワンライナーのほうが良さそう。


ついでにこっそりビジュアルベルのメッセージをオプションで設定できるようにするパッチも出そうかと思ったんですが。screen同様"Wuff! -- Wuff!"させたかったんです。


さらに追記:
パッチですが、CVSの最新版向けに書いてあるので、バージョン1.1のソースには当たりません。といっても、当たらないのはstatus.cだけなので、手で修正できる範囲です。

twitter怖い

bit.ly/5m2MO。ソースが明らかにフリーWebスペース（つまり、ガセ）なのに、すごい盛り上がり。twitする前に、中身を見てみようという人は少ないのでしょうか。
ちなみに、私はtwitterには居ません。kidminが別の人（組織？）に取られてしまったので。

DNS Amplificationとコンテンツサーバ

少し古い話になりますが、DNS Amplificationを使ったDDoS攻撃が話題になったことがありました。このとき、「キャッシュサーバは自組織以外からの再帰検索のクエリに応答すべきではない」と広く知られるようになり、再帰検索に応答する公開キャッシュサーバはずいぶん少なくなったように思います。
しかしながら、SANS Instituteの記事DNS queries for .で説明されているような、.のNSレコードを要求するクエリに対しては、レスポンスを返すコンテンツサーバが多いようです。
実際に、.のNSレコードを含むレスポンスは、どの程度の増幅率なのでしょうか。調べてみると、クエリサイズが17バイトであるのに対して、権威セクションのみのレスポンスの場合、レスポンスサイズは228バイトと、およそ13倍に増幅されています。また、追加セクションにルートサーバのAレコードやAAAAレコードが含まれているとサイズは512バイトにまで膨れあがり、増幅率はおよそ30倍となります。IPヘッダとUDPヘッダ込みで調べてみると、クエリサイズが45バイトであるのに対して、権威セクションのみのレスポンスの場合、レスポンスサイズは256バイトと、およそ5.7倍に増幅されています。また、追加セクションにルートサーバのAレコードやAAAAレコードが含まれているとサイズは528バイトにまで膨れあがり、増幅率はおよそ12倍となります。
いくつかのコンテンツサーバについて、.のNSレコードを要求したとき、どのような挙動を示すのか調べてみました。

DNSサーバ NS .への応答 追加セクション A www.example.comへの応答 組織
za.akamaitech.net 有 有 NSレコード+追加セクション Akamai
ldns01.data-hotel.net 無 - 無 ライブドア
ns1.dns.ne.jp 無 - 無 さくらインターネット
ns1.google.com 無 - 無 Google
dns0.iij.ad.jp 有 無 NSレコード IIJ
ns01.jprs.co.jp 有 無 NSレコード JPRS
ns1.meti.go.jp 有 無 NSレコード 経済産業省
g2.nstld.com 有 有 NSレコード+追加セクション VeriSign
ns1.ocn.ad.jp 有 無 NSレコード OCN
ns02.otnet.co.jp 無 - 無 OTNet
kasumi.cc.tsukuba.ac.jp 有 有 NSレコード 筑波大学
dns1.nc.u-tokyo.ac.jp 無 - 無 東京大学
ns.tokyo.wide.ad.jp 無 - 無 WIDE Project
dnsg01.yahoo.co.jp 有 有 NSレコード+追加セクション Yahoo! Japan

意図的に大きなサイズのレコードを持つDNSサーバを用意し、公開キャッシュサーバを利用する方法に比べて効率は落ちますが、コンテンツサーバは世界中に大量に存在し、さらに.のNSレコードに応答するサーバも多いことから、増幅効果は充分であると考えられます。また、DNSSECに対応すると、さらにパケットサイズが増大することが見込まれます。「再帰検索のクエリに応答しない」だけでなく、「自分が権威を持つゾーンへのクエリ以外には応答しない」ことも、コンテンツサーバにとって必要ではないでしょうか。


参考:
DNS の再帰的な問合せを使った DDoS 攻撃の対策について (JPRS)
DNS ampの踏み台サーバになるのを防ぐ（コンテンツ・サーバ編） − ＠IT