_ 予定が狂いまくりですわ。
_ 昔の古い町並みが残ってるのはいいことではあるんだけど、商売っ気を出しすぎてるとげんなりするねぇ。まあ、こういう商売をしてるからこそやっていけてるんだろうからそれが悪いとは言わないけどさ。
_
飛騨高山
白川郷
_ 今日で震災から半年というのもそうなんだけど、9.11 テロから10年でもあるんだよな。10年前、生まれて初めての海外行きでその前日に US 入りしてヒドい目にあった。行き先はテロの攻撃があったところからかなり離れてて直接なにかあったわけじゃないけど、それでも予定していたことがまったく何もできなくなって、空港が再開するまでの間ホテルで CNN を見る以外なにもすることがなかった。おかげで evacuate という単語を覚えた。CNN で The Whitehouse is evacuated. The FBI is evacuated. てなテロップがずっと流れ続けてたのが強烈に記憶に残ってる。
_ あ、10年てことは、パスポートの有効期限切れてんじゃん。2回しか使ってない。
_ 震災から半年経ち、9月も半ばになってまだまだ暑いけれどもクソ暑いというほどではなくなってきたので、節電モードを解除。半年間デスクトップ PC の電源は落としてずーっとノート PC だけで仕事してたけど、以前のようにデスクトップ機を使うことにした。たった半年だけど OS もアプリもアップデートがけっこう多くて、まともに仕事できるようになるまで2時間ぐらいかかった。
_ 画面が広々してて泣けてくるね。広すぎてマウスカーソルを見失う。ノート PC の方も、なんでもかんでも1台でこなしてた処理の全部をやる必要がなくなったおかげでメモリ不足が解消して、イライラがだいぶ減った。金をかけずにマシンのスペックを上げるには、もっとスペックの低い環境でしばらく暮らせばいい、なんてジョークがあるけど、うん、真実だ。まあ、どうせすぐ慣れるんだろうけど。
_ 8.8.8.8/8.8.4.4 の Google Public DNS がいつのまにか日本に来てた。日本から使う場合、 以前は台湾だか東南アジアだかわかんないけどたぶんそのあたりにルーティングされてた。国内にあれば RTT は 10ms 以下があたりまえだけど、日本にないのでとっても遅く 40ms ぐらいかかってた。ところが、いつのまにやらふつーに 10ms 以下で応答が返ってくるようになってる。国内に拠点を確保したみたいだね。
8.8.8.8 が速いと信じて疑わない人ってきっと騙されやすくて壺とかほいほい買っちゃうんだろうなぁとか思ってたんだけど、世間一般並みの速さで応答されるようになって笑っていられなくなった。> ping -c 5 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=8.147 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=8.181 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=7.992 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=7.885 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=7.977 ms --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.885/8.036/8.181/0.111 ms_ まあ、8.8.8.8 が日本に来て速くなったといっても、もともと国内にある DNS を使った場合に比べて有利とはかならずしも言えないんだけどね。実例:
google public dns に教えてもらったアドレスにアクセスしにいくと、google dns を使わなかった場合の15倍の時間がかかってる。むちゃくちゃ遅い。> dig +short www.asahi.com www.asahi.com.edgesuite.net. a1403.b.akamai.net. 117.104.135.66 117.104.135.51 > ping -c 5 117.104.135.66 PING 117.104.135.66 (117.104.135.66): 56 data bytes 64 bytes from 117.104.135.66: icmp_seq=0 ttl=55 time=8.105 ms 64 bytes from 117.104.135.66: icmp_seq=1 ttl=55 time=7.262 ms 64 bytes from 117.104.135.66: icmp_seq=2 ttl=55 time=6.891 ms 64 bytes from 117.104.135.66: icmp_seq=3 ttl=55 time=7.331 ms 64 bytes from 117.104.135.66: icmp_seq=4 ttl=55 time=7.705 ms --- 117.104.135.66 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 6.891/7.459/8.105/0.414 ms > dig +short www.asahi.com @8.8.8.8 www.asahi.com.edgesuite.net. a1403.b.akamai.net. 67.148.47.42 67.148.47.27 > ping -c 5 67.148.47.42 PING 67.148.47.42 (67.148.47.42): 56 data bytes 64 bytes from 67.148.47.42: icmp_seq=0 ttl=54 time=120.196 ms 64 bytes from 67.148.47.42: icmp_seq=1 ttl=54 time=115.555 ms 64 bytes from 67.148.47.42: icmp_seq=2 ttl=54 time=109.316 ms 64 bytes from 67.148.47.42: icmp_seq=3 ttl=54 time=108.951 ms 64 bytes from 67.148.47.42: icmp_seq=4 ttl=54 time=120.189 ms --- 67.148.47.42 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 108.951/114.841/120.196/4.960 ms_ akamai みたいな CDN サービスは、世界の各地にサーバを置いて、クライアントからいちばん近いサーバに誘導している。といっても、クライアントがどこにいるかなんてのは CDN 業者からはわからないので、名前解決に使われた DNS サーバからいちばん近いところが選ばれるような仕組みになってる (*1)。で、google dns は日本にやってきたけど、CDN 屋さんからしたら日本にあるとは認識されていないようで、100ms 以上かかる非常に遠いサーバにアクセスしろと言われる。DNS の応答が速くなっても、その次の HTTP アクセスがむちゃくちゃ遅くなるので、今のところはやっぱり 8.8.8.8 を使うのは不利。とはいえ、それほど遠くない時期に CDN を使ってもちゃんと近いサイトに誘導されるようになるだろうから、そうなったらほんとに google dns でも速度的な問題はなくなるだろうね、きっと。
_ 予定が狂いまくりですわ。
_ 昔の古い町並みが残ってるのはいいことではあるんだけど、商売っ気を出しすぎてるとげんなりするねぇ。まあ、こういう商売をしてるからこそやっていけてるんだろうからそれが悪いとは言わないけどさ。
_ 飛騨高山
白川郷
_ 期待してなかったのに。つーか暑い。
_ 日本中くまなくまわったわけではないけど、それでもけっこういろんなところを走ったと思う。その中で走ってていちばん楽しい道といえば、北海道や信州の道ではなく、能登半島の千里浜なぎさドライブウェイだと断言する。日本で唯一、砂浜を走れる道路。道交法も適用されるれっきとした道路。未舗装だけど。
_ 今回はここに来るのがいちばんの目的だったので、思いかけず晴れてくれてたいへんありがたい。ここを走るのは5年ぶりくらいだけど、やっぱりすげー楽しい。
_ あと、能登半島一周してきたけど、まあオマケなんで。
_ 海の家(ドライブスルー)
道交法では軽車両扱いだったはず
路肩で地引き網
_ 萎えたので、どこにも寄らずにまっすぐ帰る。高速に乗らずに下道だけで。
_ …のつもりだったんだけど、思いのほか時間がかかったので途中から高速に。が、高速に乗ってすぐに「渋滞 40km 2時間」とかいう表示にめげてまた下りる。そういう情報は IC の手前に表示しといてくれよ。
_ 来週の3連休は晴れてくれよ。
DNSユーザからの要求を受け取る8.8.8.8が日本国内にあったとしても、DNSキュエリーをDNS権威サーバに送信する送信元アドレスが同様に東京にあるとは限らないという気もし始めていますが、たぶんそうでしょう。_ うちの DNS サーバに飛んでくるクエリを眺めながら
とかキャッシュに入ってなさげな名前を聞くと、64.233.182.81 とか 72.14.202.85 とかいうところから名前を聞きにくる(8.8.8.8 から聞きにくるわけではない)。後者は 以前観測したのと同じところかな。% dig nonexistent.maya.st @8.8.8.8だいたい 40ms ぐらい。国内にあって単に遅いだけ、という可能性もないではないけど、まあたぶん海外だな。ちなみに、v6 版である 2001:4860:4860::8888 と 2001:4860:4860::8844 もだいたい同じくらいの RTT で、これも日本には来てないらしいと推測される。> ping -c 5 64.233.182.81 PING 64.233.182.81 (64.233.182.81): 56 data bytes 64 bytes from 64.233.182.81: icmp_seq=0 ttl=51 time=40.794 ms 64 bytes from 64.233.182.81: icmp_seq=1 ttl=51 time=40.229 ms 64 bytes from 64.233.182.81: icmp_seq=2 ttl=51 time=39.777 ms 64 bytes from 64.233.182.81: icmp_seq=3 ttl=51 time=41.676 ms 64 bytes from 64.233.182.81: icmp_seq=4 ttl=51 time=38.784 ms --- 64.233.182.81 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 38.784/40.252/41.676/0.970 ms_ ということで、google public dns のキャッシュに入ってない名前の解決は、クライアント→google(日本)→google(海外)→権威 DNS という流れでおこなわれているらしいことが推測される。権威 DNS が日本にあるのであれば、問い合わせはけっきょく海の向こうを往復することになるので大して速くならない。ただし、いったんキャッシュに入ってさえしまえば、あとは google(日本) が持つキャッシュで用が足りるのでふつーに国内にある DNS と同程度の速度にはなる。google のキャッシュに入ってないようなよほどマイナーなサイトにアクセスするのでなければ、まあ気にする必要はない。akamai などの CDN 屋に収容されてるサイトへのアクセスは DNS 検索が速くなっても HTTP は遠いサーバを掴まされるという問題に比べればささいなこと。
_ そういえば、何ヶ月か前に DNS を使った CDN 屋の高速化で妙なものを見つけたんだった。
_ 発端は、キャッシュサーバの IP アドレスの近傍 /24 の範囲から、妙な DNS クエリが出てるのを発見したこと。何が妙って、そのクエリを出している IP アドレスを使ってるホストが存在しないってことだよ。存在しないアドレスからクエリが出てる、つまりソースアドレス偽造のパケットが投げつけられてるんだな。ソースアドレスを詐称するととーぜん応答を受け取れなくなるので、受け取る必要のない何らかの攻撃なのではないかと調査をしたんだけど、穴を狙うような性質のパケットではなかった。
_ さらに調べてみると、そのソース詐称クエリは、どうやらすべて中国にある CDN 屋が運用しているサイトの名前を聞きにきてるようだった。どうやら、その CDN 屋が運用しているサイトへアクセスする際の DNS 検索のタイムラグを減らすために、他人が使ってるキャッシュサーバにクエリを送りつけてキャッシュを温めるのが目的らしい。たかだか数十ミリ秒縮めるためにそこまでするか。アドレスを詐称するのは、キャッシュ DNS のアクセス制限を回避するためと思われる。名前を調べるのが目的ではなくキャッシュに入れるのが目的だから応答を受け取る必要もないし。
_ その CDN 屋の運用している DNS サーバの方でもクエリを監視していて、その DNS に名前解決要求してきたアドレスに対して「キャッシュ温め攻撃」を始めるらしい。これを発見したキャッシュサーバはクライアントからクエリを受けるアドレスと、外に再帰検索しにいくアドレスを別のものにしていたんだけど、後者の方にしか詐称クエリが来てない。
_ 数十 qps ぐらいのけっこうな数のクエリを投げてくるのでブロックしておきたいのだが、こいつが厄介なのはソース詐称してるから IP アドレスでふつーにブロックしたら止めちゃいかんものまで止めちゃうのだ。今回発見したサーバのように、外に再帰検索しにいくアドレス(=攻撃を受けるアドレス)ではまっとうなクライアントからクエリを受けないような構成になっているのであれば、そのアドレスへのクエリを全部止めちゃえばいいだけなのでそれほど難しくはないんだけど、そうでないなら組織内のアドレスに詐称したパケットが組織外から入ってこれないように DNS サーバではなくルータでの対処が必要になる(あれ、ちゃんと ingress filter 入ってたはずなんだけど…)。