中国DNSルートサーバ停止事件でNetNodが調査経過公表

2010/4/1-1

先日の「中国国内ルートDNS停止事件雑感」の続報です。 I Root Serversを運用管理するNetNod社CEOのLindqvist Kurt Erik氏がdns operationsメーリングリストに調査の経過に関する情報を送信しました。まだ調査は続行中のようですが、ひとまずNetNod社が把握している状況が声明として公開された形です。

「[dns-operations] Odd behaviour on one node in I root-server (facebook, youtube & twitter)」

これを読んだ感想ですが、思ったよりもややこしい話になるかも知れませんね。場合によっては、中国からi.root-servers.netが撤退せざるを得ない状況が生まれてしまうのかも知れません。

以下、中国のDNSルートサーバ事件のその後と、それに関する私の妄想です。

NetNod社の声明内容

dns operationsに送信された声明文には以下のような内容が含まれいました。下記は一部だけなので、詳細は実際の文章をご覧下さい。

NetNod/Automaticaのi.root-servers.netは、IANAによって提供されているデータに100％沿って運営され続けている。 IANAルートゾーンの正しいデータを送信し続けることを保証している。
Queryが発生する場所によって回答を変更するようなことは無い。
北京のi.root-servers.netに送信されたQueryに対する、間違った回答が戻る問題で、いくつかのテストを実行後に、i.root-servers.netサービスの広告(アナウンスメント)を停止した。現在も停止状態は継続中である。
インターネットではパケットは複数のサービスプロバイダを経由するものであり、DNSSECのようにパケットの完全性(Integrity)を確保する仕組みがなければ、送信されたパケットがそのままの形で相手に届く事を保証するのは難しい。
間違った返答が発生するのは北京のi.root-servers.netに対するQueryのみである。北京以外のi.root-servers.netインスタンスで同様のレポートは無い。
NetNod社のi.root-servers.net北京設置インスタンスは正常である。侵入された形跡もないし、他のi.root-servers.netと全く同じ挙動で動作し続けている。
CNNICと一緒に現在も調査中である。
CNNICとともに、サービスを再度復帰させることを目指す。

中国国内からtracerouteしてみる

i.root-servers.netの経路広告停止というのは、どういったものか不思議に思いました。中国国外に経路が出ないようにしたのか、もしくは中国国内でも経路が流れないようにしたのかが不思議に思いました。

中国国内のISPによって提供されているいくつかのLooking Glassを利用して、中国国内からi.root-servers.netに対するtracerouteを行ってみました。

利用したLooking Glassサービスは、Linkwan Beijing (AS4808)のものです。 http://www.linkwan.com/en/tr.htm

この結果を見る限り、北京にあるLinkwanからi.root-servers.netへの通信は、北京→上海→日本→スウェーデン、という経路を辿っているように見えます。日本を通過するだけで、日本にあるi.root-servers.netインスタンスに行かないのが微妙に不思議な気がしますが、i.root-servers.netを運営するNetNodがスウェーデンの会社であることと、今回のtraceroute結果は関連があるのでしょうか？。。。と思ったのですが、最後のi.root-servers.netはスウェーデンではないですね。

上記tracerouteの最後の一ホップであるi.root-servers.netの手前が日本のdix-ieになっています。これは恐らく、IP anycast用として利用されている192.36.148.17というIPv4アドレスの所在地が「スウェーデン」となっているだけであり、パケットがスウェーデンのストックホルムに飛んでいるわけではないですね。 IP anycastとGEO Locationの相性は最悪ですね（笑）。

ということで、現時点で、AS4808からi.root-servers.netへのパケットは、北京→上海→日本、という流れ方をしているようです。

この観測結果から、恐らく中国国内のIルートサーバは停止状態にあるものと思われます。もし、中国国内でi.root-servers.netが稼働していたら、ワザワザ海を越える結果にはならずに、北京内で全て完結するtraceroute結果になりそうです。

（余談ですが、LinkwanのGoogle Mapsとtracerouteの組み合わせってカッコイイですね）

やっぱり第三者が改ざんDNSパケットを投げてそう

NetNodの声明は、恐らくその通りだろうと推測しています。 dns operationsに投稿されたメール中で示されているdig結果は以下のようになっています。


$ dig @i.root-servers.net www.facebook.com A 

; <<>> DiG 9.6.1-P3 <<>> @i.root-servers.net www.facebook.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7448
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

私の環境からは日本国内にあるi.root-servers.netが見えますが、そこに対するdig結果は、dns operationsに投稿されたものと違います。


> traceroute i.root-servers.net
...(中略)...
 7  as8674.dix-ie.jp (202.249.2.180)  12.498 ms  12.485 ms  12.440 ms
 8  i.root-servers.net (192.36.148.17)  12.507 ms  12.481 ms  12.456 ms

私の手元では、以下のようにAA(Authoritative Answers)とRA(Recursion Available)のフラグが立っていません。



;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

i.root-servers.netの全てのインスタンスが全く同じ回答を返す筈であれば、途中のルータが置き換えているか、もしくは同一IPアドレスの別機器が回答を返している可能性がありそうです。この結果は、必ずしもNetNodの主張を裏付けるものではありませんが、「何か違いそうだ」ぐらいのニュアンスですかね。

まあ、肝心のAレコードが全く違うので違うという点で見れば明白ではありますが。

今後の状況を妄想

今回の件は、それなりに「ニュース」になったので、NetNod社はよっぽど正当な理由もしくは状況の改善が見られなければ北京のi.root-servers.netを元の運用に戻すのは難しいかも知れません。しかし、中国でのネット検閲システムが今回の事件を解決するために緩和されるとは考えにくい気もしています。そのため、現状を受け入れて途中ルータがDNSの通信を勝手に書き換えるのを受け入れない限りは、元の状態に戻せないという状況が発生する可能性があると妄想しました。

さらに、この件が未解決なままダラダラと進んでしまうと、FとJに関しても議論が飛び火し得るのではないかと妄想しました。たとえば、「FとJに対して、中国国内でTwitter.comを問い合わせると、どうなるの？」という話は確実に登場しそうです。要は、今まで眠ってた物を掘り起こしてしまった形と言えそうです。

しかし、そうなると、今よりも状況は悪化しそうな気がします。 IANAによる公式なDNSルートサーバが全て撤退し、中国独自のルートサーバが重要な要素として定常運用されるという変な状況へと向かって行くのかも知れません。 Alternative DNS Root問題が昔からあるように、ルートサーバを構築することそのものは技術的には誰でも可能です(参考：Wikipedia:Alternative DNS root)。

2006年に、「中国が独自にDNSルートサーバを置いてインターネットを分断するらしい！」という誤報が流れましたが(PCWorld: Inaccurate Report Sparks Fears China May Split Net)、下手をするとそれがリアルになる可能性も捨てきれない気がしてきました。

今回の件で、話がこじれにこじれて、FとIとJが全部撤退する流れになってしまうと、恐らくIANA非公認のルートサーバを中国国内に置かざるを得ない状況が発生してしまうと妄想しました。「検閲」というコンテキストでは、FとIとJが撤退して自前でやらざるを得ない状況が発生した方がむしろ色々やりやすくなりますし、中国国外の「.cn」ドメインを全部閉め出したり、個人でのドメイン取得を制限したりしている時点で分断上等っぽい流れですし。

そうなったとき、中国国内専用IANA非公認ルートサーバのIPアドレスが独自だと多くのシステム内の設定を変更しなくてはならず色々と面倒なので、「正規のルートサーバIPv4アドレスを中国で使っちゃえ！」といって正規のルートサーバのIPアドレスで中国独自ルートサーバを運用すると、カオス度が上昇しそうです。現在利用されている正規ルートサーバのIPアドレスを、閉じたネットワークである中国国内で勝手に使う事を技術的に阻止するのは難しいだろうと思いますし、そうなると遺憾の意を示す以外にどうしようも無い気もします。

さらに、独自ルートサーバという視点で見ると、最近のICANNで決定されたTLDの大幅増加計画と、その後のTLDの使われ方の流れも、もしかすると何らかの影響を与えるかも知れません。 TLDが増えたりすることがあるということは、ルートサーバが扱う情報が変化するということであり、独自ルートサーバとの相性などが発生するのかも知れません。

DNSSECと中国ネット検閲

dns operatiosのメーリングリストでは既に議論されていますが、今回の件とDNSSECは今後関連付けて語られる事がありそうです。

たとえば、DNSSEC用のDO(DNSSEC OK)フラグが立ったパケットを中国が通さないなどの措置を行った場合、DNSSECが中国で使えなくなってしまうという問題もあり、DNSSECの運用と普及が進むと同時に摩擦も増えるのかも知れません。

最後に

インターネット上では経路が漏れたりすることで、どこか特定の部分の通信に不具合が発生するというのは、さほどレアな事件とは言えない気がします。大きい事件としては、パキスタンのISPからの経路漏れで世界中がYouTubeを見られなくなる経路ハイジャック事件がありますが(参考：CNET:YouTubeがダウン--原因はパキスタンでのアクセス遮断か)、小さな事件はちょくちょく発生しています。

色々調べた結果、個人的には事件そのものは、さほどインパクトがあるものとは思いませんでしたが、GoogleやGoDaddyのコンテキストが存在する状況下では、ある意味、本格的なAlternative DNS Root問題へと向かいそうな不気味さを秘めている気がしてきました。

今のところは「調査用にi.root-servers.netの北京インスタンスが停止されている」という状況なので、まだそこまではおおごととまでは言えないのかも知れませんが、GoogleやGoDaddyの流れによる人々のニュースの受け止めかたという側面が強いため、今後の推移に注目する必要がありそうだとは思いました。

こんなの考え過ぎで、こんな妄想的な予想は外れて欲しいと思う今日この頃です。

おまけ

「なんでチリから中国に行っちゃうの？」と疑問に思った人もいるかと思いますが、i.root-servers.netを求めてチリから中国へと行ってしまうのは、そんなに変ではない気がしています。

今回問題発生が報告されているTelmex Chile(AS6429)からi.root-servers.netを現時点で試すと、タイのバンコクへと行きます。

利用したのはTelmex Chileが提供しているLooking Glassサービスです。
http://lg.telmexchile.cl/trace.php


 1  200.27.2.3 (200.27.2.3)  0.367 ms  0.157 ms  0.229 ms
 2  10.20.10.19 (10.20.10.19)  0.500 ms  0.409 ms  0.485 ms
 3  200.27.5.1 (200.27.5.1)  0.737 ms  0.708 ms  0.735 ms
 4  200.27.5.237 (200.27.5.237)  0.993 ms  0.669 ms  0.984 ms
 5  200.27.5.110 (200.27.5.110)  0.986 ms  4.108 ms  0.984 ms
 6  san2-telmex-7.san.seabone.net (195.22.221.109)  1.192 ms  0.981 ms  0.882 ms
 7  * * *
 8  mia5-san11-racc1.san.seabone.net (195.22.221.189)  276.657 ms  276.561 ms  276.627 ms
 9  new11-mia5-racc1.new.seabone.net (195.22.216.220)  319.507 ms  319.293 ms  320.318 ms
10  mil26-new11-racc8.mil.seabone.net (195.22.205.72)  308.533 ms  371.255 ms  308.026 ms
11  pal16-mil26-racc5.pal.seabone.net (213.144.181.4)  312.977 ms  314.092 ms  317.698 ms
12  pal9-pal16-racc2.pal.seabone.net (195.22.218.61)  308.951 ms *  309.323 ms
13  customer-side-cat-telecom-3-id-pal9.pal.seabone.net (195.22.197.194)  484.571 ms *  483.526 ms
14  * 61.19.9.29 (61.19.9.29)  486.131 ms  486.253 ms
15  61.19.9.70 (61.19.9.70)  483.120 ms  483.116 ms  484.539 ms
16  61.19.10.38 (61.19.10.38)  484.659 ms  484.382 ms  484.652 ms
17  202.47.247.101 (202.47.247.101)  489.205 ms  488.905 ms *
18  202.47.247.182 (202.47.247.182)  487.087 ms  487.660 ms  487.267 ms
19  202.47.250.147 (202.47.250.147)  482.361 ms  483.003 ms  485.232 ms
20  * i.root-servers.net (192.36.148.17)  483.276 ms *

done ...

seaboneのWebに掲載されているネットワーク図を参考にすると、チリ(サンティアゴ) → ニューヨーク → ミラノ → パレルモ → 最終的にタイのバンコク、という流れでi.root-servers.netへと到達しているような気がします。

今回の事件とは全く関係が無い中国のサーバに対してtracerouteをしたので、ここでは結果を表示しませんが、チリのTelmexから中国へのtracerouteも同様にseaboneを通過しました。 (ただし、今回試した中国のアドレスがi.root-servers.net北京インスタンスの近くではない可能性も高いので、この結果はあまり参考にならないのでご注意下さい)

もしかすると、チリからi.root-servers.netを見ようと思った時、中国と現在の結果であるタイは、ネットワーク距離的には「ちょっとした違い」なのかも知れません。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！