Web屋のネタ帳

ある特定のWebサイトを見るだけでパソコン全体の調子が悪くなる ということは通常ありえない。よほど古いＰＣ＝古いブラウザ＝HTMLやJavaScriptやVbscriptなどの処理系が古すぎて 最新仕様に対応しきれていないブラウザ＝ならばもしかしたらありうるかもしれないが、めったにない。 まして、パソコン(のOS)やブラウザの調子が悪くなるだけでなく ルーターなどの周辺機器にまで影響を及ぼすとは考えにくい。

「あるWebサイトだけ見れない／見るとパソコンの調子が悪くなる」 ということを言うユーザーはたま〜〜にいる。 Webコンテンツ上に寄生しブラウザの脆弱性をついて入り込んでくるタイプの コンピュータウィルスに感染してしまったとか、 ブラウジング中に突然でてくるダイアログボックスで何も考えずに「はい」 ばかり押しているうちによからぬActiveXコントロールでも入れてしまったとか、 単にルーターのコンセントやLANケーブルの接触不良だとか、 ほとんどのケースはそういう原因だろう。

しかし事実は奇なり。

eBayのWebサイトにアクセスした DSLユーザーのシステムがクラッシュしたとの苦情が、 数カ月前から寄せられている。
　問題は、ルータを再起動することで解決できる。 DSLモデム内蔵のルータでは再起動に数分かかるため、 そうしたルータのユーザーは、eBayの利用を不快に感じて苦情を報告するケースが多い。
eBayへのアクセスでDSLルータのシステムに不具合 (ITmedia 2004/9)
※eBayは欧米で超有名なオークションサイト。 日本のヤフオクなんてメじゃないくらい大規模。

アクセスしただけでブラウザじゃなくルーターをクラッシュさせる Webサイトって、ある意味すごい高等テクだ。(笑) しかしそれが、eBayという超有名巨大サイトで起こってしまった。

ネタ元を要約＆意訳＆補足すると、現象と原因は次のとおり。

• eBay上に出品されている商品のページを閲覧すると、 その直後から一切のネットワークアクセスができなくなる。
• PC自体やそのアプリ(ブラウザ等)のせいではないらしい。 ルーターを再起動すると直ることから、ルーター（の内部のファームウェア）がクラッシュするようだ。 しかしなぜ？
• 実はeBay上の商品ページでは、アクセス解析用のビーコンが埋め込まれている。 eBayオリジナルではなくeBayが提携している解析専門ベンダーによるもののようだ。 日本でも似たようなASP型アクセス解析サービスは珍しくない。
• ビーコン画像(よくあるタテヨコ1ドットの透明画像と思われる)を送り出す解析サーバのURLは、 13キロバイトにもおよぶJavaScriptによってそのURLが決定されるというものだった。 このURL、長いのだ。何が長いって、なんじゃこりゃ？↓

  http://e-n.y-1shz2prbmdj6wvny-1sez2pra2dj6wjkywkajcboq2dj6x9ny-1seq-2-2.stats.example.com/
  (ここではわざとexample.comに直してあります)

  おそらく、eBay上の各ページ＝商品＝ごとにアクセス解析するために、 各ページ上のJavaScriptで個別のURLを自動生成しているものと思われる。 それにしたって普通はQUERY STRING＝URLの最後のほうに?とか&を使ってくっつける変数＝を 使うものだが、このアクセス解析サービスは、 アクセス解析に必要な情報を示す文字列をURLのホスト名部分に埋め込むという、 奇抜な方法を取っていたらしい。 たしかに、DNSのワイルドカード設定を使えばこういう方法も可能だ。 コロンブスの卵的発想（？）。
• ところが、この長いホスト名こそが、原因だった。 古いタイプのxDSL回線向けルーターのファームウェアのDNS機能にバグがあり、 ドメイン部分の各ラベル(ドットとドットの間の文字)が51文字以上あるホストをDNS検索しようとすると、 ファームウェアがクラッシュしてしまうのだ。 するとルーターの全てのネットワーク機能が停止してしまう（or停止したように見える）。 おそらく、ファームウェアのコードを書いた人間が URLのホストのラベル部分の長さの最大値は50バイトであると、 低く見積もってしまっていたのだろう。 それ以上の値を与えるとバッファがあふれてエラーを起こしダンマリ状態になってしまう。
• ビーコンのURLはJavaScriptによって生成されるのでソースを見ただけではどんなURLなのかわからないし、 また、ビーコンを埋め込んでいる商品ページはeBay上のプロの法人による出品ページだけで、 個人による出品ページには埋め込まれていない。 そもそも比較的新しいルーターではこういったバグは無いようだ。 そういったことが、問題点の切り分けと原因の発見を遅らせてしまったと考えられる。 だいいち、特定のサイトを見ることとルーターのクラッシュが結びつくなんて、 普通の人は考えも及ばないだろうし。

教訓

RFC1035 ドメイン名−実装と仕様書には、 「ドメインのラベルは63オクテット以下」（つまり63バイトまでならOK）と はっきり定められている。 ファームウェアのコードを書いた人間はこの規定を無視した or 知らなかった or 調べもしなかった可能性が高い。 つまり「とりあえず５０バイトとっときゃいいだろ」と安易に決めてしまったのだろう。

そもそもインターネット上で使うアプリケーション仕様や通信プロトコル仕様は、 全てRFCで定められた仕様に準拠していなければならない。 皆がてんでバラバラの仕様でソフトを作ったところで 相互の通信がうまくできるわけがないからだ。 つまり、RFCを読まずにネット関連のソフトを書いてはいけない。

実際のところ、最近Webアプリをつくりはじめた人で、 ナマのRFC文書をひとつでも真剣に読んだことのある人はそう多くないと思う。 また、Webアプリに限らずたとえば単にデータベースのテーブル仕様を決めるときに、 「うーん、このフィールドはvarchar(50)くらいでいいかな」と 適当に決めてしまってあとで「しまったぁ・・・」という経験はないだろうか？ 筆者にはある。（笑） だがそういうことをしていると、 思わぬところで甚大な規模の迷惑がかかってしまうかもしれないということを、 肝に銘じよう。

しかしだからといって、今回のケースでの責任の所在が、 RFC準拠しているドメイン名を処理できないようなルーターのファームウェア（を書いた人）だけにあり、 アクセス解析サービスを作った側には全く非は無いか、というとそうでもないと思う。 少なくとも1%くらいは責任があるはずだ。

そもそもドメインネームシステム(DNS)とは、IPアドレスという数字の羅列では わかりづらいし、IPが変わったときにそれをあちこちに通知するのも大変だから、 アルファベットも使えるドメインネームというものを定めて、わかりやすくしよう、 というのが本来の目的だ。 アプリケーションで使用する細かい変数を伝達するためにドメイン名を使う というのは全く本来の想定外である。

どんな技術、道具、方法論を使う場合でも、 皆が想定している使い方を逸脱すればどこかで必ずトラブルが起こる。 DNSのワイルドカード設定で思い出したが、 去年のSite Finder事件でベリサイン社が総スカンをくらったときに 「われわれは全てのRFCに準拠している」と開きなおったっけ。 (注：ベリサインのこの言い分はRFC1035の曲解と言える。詳しくは下記参照）

Verisign問題、どこがどう問題なのか？(2003/9)
ICANN、VeriSignの“Site Finder訴訟” を棄却するよう米連邦地裁に請求(2004/4)

「技術的にできること」と 「やっていいこと、つまり世間の人やモノがそれを受け入れる準備があること」 は次元が別である。 ちょっと極端な例だが「できるからと言ってヒトの遺伝子を安易にいじくりまわしてはいけない」 といったことと同じだ。 技術ばかり見ているエンジニアや研究者はえてしてこのワナにはまりやすい。