Opera + Togetter.com = 404 ? まとめ

概略

Opera で Togetter.com に繋げられない問題は AWS の DNS が最短 60秒で切り替わるのに，Opera が内部でキャッシュしていてドメインを正常に解決できていないことが原因と推定．以下，起きていた現象と調査した内容について記述し，最後にとりあえずの対処法を検討してみる．

対処法まで飛ばす

追記

誤解を招いてもつまらないので，一応補足．

AWS ELB では，最低でも1時間は再利用しない ..“)と言っているが TTL (60) がそもそも問題で，その他いくつかの理由で DNS サーバが返してきた TTL をブラウザが意図的に無視するようになっているので（1,2,3 ）「Opera が悪い」かどうかは微妙なところ．

Firefox の about:config#network.dnsCacheExpiration とか Chrome の chrome://net-internals/#dns みたいな手段があればいいんだけど．

追記の追記

場合よっては IEでも起きる問題なので Opera の問題ではないです．

ザ・インタビューズ、こういう状態なんだけど、私だけかしら

ザ・インタビューズ theinterviews.jp とケータイ国盗り合戦 kntr.jp も AWS を利用していて，問題の構造としては同じ．

まえがき

7月頃から，Opera で Togetter につながらないとかいう話がぽつりぽつりと，2chの総合スレや amatanoyo がはてダで言及されていて，当然ながら twitter でも繋がらないとか404 が出る，別のサイトが表示されるといった言及が観測されてた．

PC や Opera の再起動で直ったという事例もあったので，Opera の設定やプロファイルの問題じゃなくて，ネットワークの問題でしばらく前の IPv6 で bit.ly が開けない問題の時と同様に問題ない人には全く問題が起きなくてと踏んでいて，実際 08/10 に一度 404 が表示されたことはあったものの，Opera の異常終了で再起動したら正常につながっていたので緒もつかめてない状態だった．

が，08/11 の午後になって別の環境で何度となくつながらなくなったので，改めて，いくつかの言及をたどりつつ，調べてみた．

観測されてた事例

他のサイトに飛ばされる

事例1

Opera使いですが、togetterを見ようとすると毒女ニュースに飛ばされます・・・。数日前まで普通に見られたのに。 - Operaでtogetterが見られないらしい。 - あまたの何かしら。 (@amatanoyo http://d.hatena.ne.jp/amatanoyo/20110729/1311914142

毒女ニュースのURL はたぶんこれ．

事例2

Opera総合スレッド　Part169 http://hibari.2ch.net/test/read.cgi/software/1312156532/501

501 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2011/08/12(金) 20:50:17.53 ID:sDQLOe740

AVGさんは何も発見してないんだがなあ、特にぁゃιぃもの入れた心当たりもないし
もしそうだとしても何故Operaだけ
Operaだけ再インスコすればいいんだろうか

ちなみにOperaの設定を変えても今の所100%起きる
現象は
http://togetter.com/
にOperaでアクセスすると、
http://cn-monitor.macromill.com/
が表示されるということのようだ

http://cn-monitor.macromill.com/monitor/ はマクロミルという会社の繁体字圏会員サービスのページのようだが詳細はこの際関係ないので調べてない．

この他に，東京都の職員採用のページ（恐らく東京都職員採用2012 のページ）に飛ばされたという tweet があった．

コナミのページに飛んだ例は，スクリーンショットからすると http://football.allstars.konami.jp/ でやはり，AWS ELB

その他の事例

事例2と同一人物だが，HTTP の 404 や 503，そもそもつながってないという現象が発生していた様子．

Opera総合スレッド　Part169
http://hibari.2ch.net/test/read.cgi/software/1312156532/414
414 ：名無しさん＠お腹いっぱい。[sage]：2011/08/11(木) 00:55:04.84 ID:eU//7tuJ0
ちなみに繋がらないと言っても現象は様々で
ApacheのNot Found画面
「サービスが高負荷であるかオフラインになっています。後で再試行してください。」というOperaのメッセージ
読み込み中のまま、全く応答なし
と色々。
他のブラウザからだと普通に見れる
他のサイトをOperaで見ても普通に見れる
togetter.comをブロックしたりはしてない
hostsが書き換えられてもいない

共通する事柄

そもそもつながらないといった事例は除いて，飛ばされていた別のサイトに共通するのは，全て AWS の上に構築されていて，なおかつ AWS ELB を使っていることである．

それぞれのドメインを dig して answer だけとりだすとこうなる．（TXT は省略．2011-08-15T22:00:00+0900 前後の結果．）

毒女ニュース officiallyjd.com

[office@ashula.info]$ dig officiallyjd.com any @8.8.8.8
; <<>> DiG 9.8.0 <<>> officiallyjd.com any @8.8.8.8
officiallyjd.com.                                             1200 IN CNAME  my-load-balancer-2009010510.ap-northeast-1.elb.amazonaws.com.
my-load-balancer-2009010510.ap-northeast-1.elb.amazonaws.com. 60   IN SOA    ns-947.amazon.com. root.amazon.com. 1313412207 3600 900 7776000 60
my-load-balancer-2009010510.ap-northeast-1.elb.amazonaws.com. 600  IN NS     ns-947.amazon.com.
my-load-balancer-2009010510.ap-northeast-1.elb.amazonaws.com. 60   IN A      46.51.243.211
my-load-balancer-2009010510.ap-northeast-1.elb.amazonaws.com. 60   IN A      46.51.243.224

マクロミルの繁体字サイト cn-monitor.macromill.com

[office@ashula.info]$ dig cn-monitor.macromill.com any @8.8.8.8
; <<>> DiG 9.8.0 <<>> cn-monitor.macromill.com any @8.8.8.8
cn-monitor.macromill.com.                                        763   IN  CNAME   mmproxy-cn-monitor2-1717042642.ap-northeast-1.elb.amazonaws.com.
mmproxy-cn-monitor2-1717042642.ap-northeast-1.elb.amazonaws.com. 60    IN SOA ns-927.amazon.com. root.amazon.com. 1313412530 3600 900 7776000 60
mmproxy-cn-monitor2-1717042642.ap-northeast-1.elb.amazonaws.com. 600   IN NS ns-927.amazon.com.
mmproxy-cn-monitor2-1717042642.ap-northeast-1.elb.amazonaws.com. 60    IN A 46.51.242.195

東京都の職員採用ページ

[office@ashula.info]$ dig www.saiyou2.metro.tokyo.jp any @8.8.8.8
; <<>> DiG 9.8.0 <<>> www.saiyou2.metro.tokyo.jp any @8.8.8.8
www.saiyou2.metro.tokyo.jp.                                              356 IN CNAME   metro-tokyo-jp-load-balancer-312667999.ap-northeast-1.elb.amazonaws.com.
metro-tokyo-jp-load-balancer-312667999.ap-northeast-1.elb.amazonaws.com. 60  IN SOA     ns-916.amazon.com. root.amazon.com. 1313412657 3600 900 7776000 60
metro-tokyo-jp-load-balancer-312667999.ap-northeast-1.elb.amazonaws.com. 600 IN NS      ns-916.amazon.com.
metro-tokyo-jp-load-balancer-312667999.ap-northeast-1.elb.amazonaws.com. 60  IN A       175.41.254.219

では，togetter.com はどうかというと，こちらも AWS 上に構築されていて，AWS Route53を用いている．

togetter.com

[office@ashula.info]$ dig togetter.com any @8.8.8.8
; <<>> DiG 9.8.0 <<>> togetter.com any @8.8.8.8
togetter.com.           86400   IN      NS      ns-93.awsdns-11.com.
togetter.com.           86400   IN      NS      ns-657.awsdns-18.net.
togetter.com.           86400   IN      NS      ns-1461.awsdns-54.org.
togetter.com.           86400   IN      NS      ns-1828.awsdns-36.co.uk.
togetter.com.           900     IN      SOA     ns-1461.awsdns-54.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
togetter.com.           60      IN      A       46.51.243.33

何度か試すと以下の A レコードが返されることもある．

togetter.com.           60      IN      A       175.41.255.252

恐らくtogetter.com も ELB を利用していると思われる．参照

起こりうる可能性

ELB を用いている 3 ドメインの A レコードも togetter.com の A レコードも TTL が 60 に設定されていて，前の問合せから 60 秒以上経ってたらキャッシュを放棄すべきということに成っている (cf. STD13)．つまり，どのサイトも基本的には，60秒経つと IP アドレスが別のものになっている可能性がある．

また ELB は，対象のサーバ（インスタンス）のネットワークアクセスの負荷に応じてインスタンスを増減させるので，アクセスが集中しているときにはいくつものインスタンスが ELB の A レコードに追加され，負荷が小さくなればそれらのレコードが削除される．この時付けられる IP アドレスは AWS の region の中から選ばれるため，以下のような状況で別のサイトに飛ばされるという現象が起こりうる．

ちなみに，46.51.240.0/20 は AMAZON-AWS-EC2-3 が，175.41.224.0/19 は AMAZON-AP-RESOURCES-JP が持ってる．

ELB を利用しているサイト A ( foo.example.com ) がアクセス増加により，インスタンスが2つになり，それらに IP アドレス 10.0.1.1 と 10.0.1.2 が割当てられる．
ユーザ a が foo.example.com にアクセスしようとすると ELB により IPアドレス 10.0.1.1 に解決される．
同じ頃別のユーザ b がアクセスしようとすると IP アドレス 10.0.1.2 に解決される．
しばらくして，サイト A の負荷が下がり，10.0.1.2 の割当てが解除される．
AWS 上の別のサイト B ( bar.example.org ) のアクセスの増加により，先ほどまでサイト A ( foo.example.com ) （のELB）に割当てられていた 10.0.1.2 がサイトB ( bar.example.org ) に割当てられる．
ここでユーザ b がサイトA に再びアクセスしようとすると，ユーザ b にとってはサイトA = 10.0.1.2 なので 10.0.1.2 へとアクセスするが，すでにサイト B に切り替わっているのでユーザ b はサイトA にはつながらないことになる．

ただし，ユーザ b がこれに遭遇することは，全てのDNSクライアントが TTL を遵守しているならまず無いと言っていい．が，実際には追記に書いたようにいろいろな事情で TTL は無視されているので下記の議論で後者の状態が現実的．

前述のシナリオでは時間の設定を省いたが，実際には時間が必要なので．

（あとで図で描く）

ユーザ b がサイトA = 10.0.1.2 と知ってアクセス
サイト A の 10.0.1.2 割当てが解除されて解決できなくなる
サイト B に 10.0.1.2 が割当てられて解決できるようになる
ユーザ b が再度サイト A にアクセスしようとする

これが 60 秒以内に起こるか，

ユーザb が TTL を無視してキャッシュを放棄せずにいる

のどちらかが起こらないとユーザ b がサイトAを見失うことは起こりえない．

仮に全てが 60 秒以内に起こったとすれば，TTL を無視しようが遵守しようが発生するためブラウザを変えても 50% の確率で起こるためもっと多くの事例が別のブラウザでも発生していなければならないが，そんなことは起きていないので，キャッシュを放棄せずにいるという可能性が高い．

とりあえずの対処法

まとまりなく書いてみたものの，Opera に DNS の解決（とキャッシュ）をさせない以外に手は無さそう．

手っ取り早い方法

Opera を再起動する．Opera の内部キャッシュが消えるので接続できる可能性は高い．

ただし，ISP の DNS がアレなど上位のネットワークの設定次第では解決しないこともあるがその場合ブラウザを変えたり再起動したりしても無駄．DNS サーバを切り替えるか寝て待つ．

解決をさせない方法．

プロキシサーバを使う．

プロキシサーバの名前解決の性能によっては同じ問題が発生する可能性はあるが，ローカルにプロキシ(キャッシュ)サーバを立てておけば他のメリットもある．

Opera Turbo を使う．

プロキシサーバの一種なので，Turbo で代用する方法もある．ただし，IP アドレスが既知なプロキシサーバとして色々とデメリットも大きい．

キャッシュをさせない方法．

今のところ，起動中に確実にキャッシュを放棄させる方法は不明．

Opera の再起動でキャッシュは消えるようだが，いちいち終了させるよりはコンテキストメニューから別ブラウザで開いたほうが速い．