中国国内ルートDNS停止事件 雑感
先日、「中国国内に配置される、DNS ルート・サーバーが閉鎖された?: Agile Cat ― Azure & Hadoop ― Talking Book 」が、はてなブックマーク上で話題になっていました。 さらに、「インターネットインフラ界のネタフル」的存在だと勝手に私が考えているyebo blogさんの記事も話題になっていました「中国にあるDNSルートサーバが不審な動きをして停止」。
最初にニュースを見た時には、結構衝撃を受けたのですが、今回の事件に関して色々調べてみた結果、実はかなりショボイ事件なのではないかと思い始めました。 今回の事件は、何か新しいものというわけではなく、単なるオペミスで数年前から存在している体制が漏れただけっぽい気がします。
個人的な私の雑感ですが今回の件は、「中国国内用のインターネット検閲システムが中国国外に漏れた結果、チリのISPに影響が出た。I DNSルートサーバに対しての細工は行われておらず、途中経路のルータが偽DNS応答を返してるだけ。中国国内ではDNS Queryに対して偽の結果が返ることがあるのは数年前からの仕様」という感じでしょうか。
以下、今回の事件の背景や個人的な推測ですが、注意が必要なのは、今回の事件に関しては技術的に何が発生したのかに関しての公式発表や、本当は何であったかに関しての詳細情報がまだ無いということです。 本当にI DNSルートサーバが事件の原因であったかや、メーリングリストで議論されていた「I DNSルートサーバだと思えるIPアドレス」の先に居た機器が、本物のI DNSルートサーバであったかを含めて、まだどれも良くわかっていません。 念のため、それを念頭に読んで頂ければ幸いです。
2009年12月の中国DNS方針変更とGoDaddy
最近はGoogleが中国から撤退したり、GoDaddyが中国の「.cn」TLD(Top Level Domain)の扱いを停止するというニュースがあったので、それに関連する話かも知れないというイメージを持ちました。 しかし、今回のI DNSルートサーバの件に関しては、恐らく無関係だと今は推測しています。
中国とDNSと言えば、昨年12月に中国のCNNIC(China Internet Network Infomation Center)が「.cn」ドメインをホワイトリスト制にすると発表したというニュースがありました。 GoDaddyによる「.cn」の取得代行事業中止も、昨年12月に行われたCNNICの方針変更が原因です。
昨年12月にCNNICによって発表された方針に関する記事としては、以下のようなものがあります。 中国国内で名前解決可能な「.cn」ドメインをホワイトリスト化するというもので、ホワイトリストに含まれないドメイン名は名前解決されなくなるというものです。
さらに、ホワイトリストに含まれるためには中国でビジネス登録を行わなければならず、それを行わないドメイン名の名前解決は中国国内で行われなくなります。 結果として、中国国外に存在する「.cn」ドメインが中国本土から見られなくなるという事態が発生することが昨年12月時点で懸念されていました。
- The Register: China moves closer to a smut-free internet
- DANWEI: MIIT considers a white-list of approved websites
- Global Times: All .cn websites require business license
今年に入ってからのGoDaddyの件に関しては、以下の記事をご覧下さい。 昨年12月から、ドメイン名取得者の顔写真、住所、電話番号、ビジネス登録番号、署名入りの申請書などが必要になったことがGoDaddyが「.cn」取得代行を行わなくなった理由であると述べられています。
- The Washington Post: In response to new rules, GoDaddy to stop registering domain names in China
- CNET News InSecurity Complex: China seeks identity of Web site operators
このようなニュースがつい最近あったので、今回の件に関しても当初は「何か新しい規制が増えたのか?」と思ってしまいました。
今回の事件雑感
事件を知った当初は、これらの流れの中で次のステップとして発生したものだと思っていましたが、色々と調べてみると、どうもこの事件は単なるオペミスっぽい気がしてきました。 何か新しい動きというわけではなく、数年前から既に実施されている中国国内用のネット検閲システムの動作がチリ国内に漏れただけである気がしてきました。
現時点での、私が考える今回の事件概要は以下のようなものです。
- 中国国内用のI DNSルートサーバの経路が漏れた
- チリ国内のいくつかのISPが、中国国内のI DNSルートサーバを参照する状態が出来上がった
- チリ国内ISPからYouTube,Facebook,Twitterなどが見られなくなった
- チリのCHINIC(Chili Network Information Center)のエンジニアがMLで質問した
- CHINICスタッフの質問から、中国にあるI DNSルートサーバが原因であることがわかった
- I DNSルートサーバを中国国内で運用しているNetNod社が中国国内にあるI DNSルートサーバの経路広告を止めた
- 「何!中国のDNSルートサーバが停止されたって!!!」とニュースになった
恐らく、今回の事件がニュースとして広まったのは、GoogleやGoDaddyの件で「中国とインターネット」という話題が注目されていたからなのだろうと思います。 蓋を開けてみれば、実はI DNSルートサーバが乗っ取られたわけでも細工をされたわけでもなさそうな気がします。 単に、数年前から知られているDNSをターゲットにした中国国内のネット検閲システム一部の挙動に思えます。 今回は、中国国内用のネット検閲システムが国外に漏れて、チリのISPが仮想的に中国の検閲網内に入ってしまい、その問題が発見されて対処されたというだけの話かも知れません。
色々探してみましたが、今回の件で「影響を受けた」と表明されてるのって、一通のメールだけで、そこで書かれているのがチリ国内の3つのISPとカリフォルニアのISPの合計4カ所だけなんですよね。 その前に発生していたYouTubeの障害とは関係が無さそうだという記事もありましたし、恐ろしくローカルな障害を発端として、たまたまニュースになった事例っぽい気がしています。
とはいえ、今回の事件の背景を知るのは面白いと思うので、色々書いてみます。
DNSルートサーバとは何か?
まず、今回の事件を知るには、「DNSルートサーバとは何か?」を知らなければなりません。 さらに、DNSルートサーバとエニーキャストも今回の事件では重要な要素です。 ここでは、まず、それらを解説します。
DNS(Domain Name System)は、FQDN(Fully Qualified Domain Name)をIPアドレスに変換するための、階層的な分散管理システムです。 DNSは複数のDNSサーバが連携することで、FQDNからIPアドレスへの名前解決を実現しますが、全てのDNSサーバの頂点に存在するのがDNSルートサーバです。 DNSルートサーバは、「.com」「.net」「.org」「.jp」などのTLD(Top Level Domain)を管理するDNSサーバのIPアドレスを返します。
Wikipediaの「ルートサーバ」項目には、以下のように記述されています。
DNSクライアントやDNSキャッシュサーバがドメイン名やホスト名からIPアドレスを引く場合、まずは自組織(LAN上やプロバイダ)のDNSサーバに問い合わせを行う。自組織上のDNSサーバは、問い合わせを受けたドメイン名やホスト名が自分自身が管理しているものではなく、かつキャッシュデータにもデータがない場合は再帰検索を行ってIPアドレスを検索する事になる。再帰検索を行う場合、DNSサーバは最初にルートサーバに問い合わせて検索対象のドメイン名(ホスト名)を管理するTLDのDNSサーバのIPアドレスをもらう。以後、順次下位ドメインのDNSを検索していき、目的のドメイン名やホスト名のIPを管理するDNSサーバを探し出して最終的なIPアドレスを得る。
DNSルートサーバは、インターネットを構成する非常に重要なシステムであり、根幹とも言えます。 このように非常に重要なDNSルートサーバですが、現時点では世界は13のDNSルートサーバによって運営されています。 各DNSルートサーバには「*.root-servers.net」という名前がついていますが、「*」の部分にはA〜Mまでのアルファベットが入ります。
昔は、13のDNSルートサーバを13カ所で運営されていたのですが、今では13のDNSルートサーバを202カ所で運営されています。 運営されている場所は、http://root-servers.org/ で公開されています。 root-servers.orgによると、日本にはF,G,I,J,K,Mの6のDNSルートサーバがあるようです。 そのうち、Mは3カ所に存在するとも記述されています。
複数サイトで一つのDNSルートサーバを運用する手法として利用されるのが「エニーキャスト(IP anycast)」という技術です。 近年のDNSルートサーバは、このエニーキャストを利用する事で負荷分散を行っています。 そのため、今回の事件の概要や影響範囲を知るには、エニーキャストとは何かを把握する必要があります。
エニーキャストを簡単に言うと「全く同じIPアドレスを持つ機器をインターネット上に複数存在させたうえで、経路を調整することでユーザが最寄りの機器へ到達できるようにする」というものです。
エニーキャストに関しては、以前も解説したので今回は割愛します。 詳細は以下の記事をご覧下さい。 また、DNSルートサーバとエニーキャストに関して、さらに詳細を知りたいかたはRFC3258をご覧下さい。
- Geekなぺーじ: Google Public DNS解説と個人的妄想の「anycast」部分
- RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses, 2002年4月
中国のネット検閲システム概要
今回の事件を考えるうえで、DNSそのものの説明の次に必要なのが、中国でのネット検閲システムに関する説明です。
中国国内のネット検閲システムは、複数の方式から成り立っており、DNSに対する細工が行われていることは数年前から知られています。 中国のネット検閲システムは「Golden Shield(金盾)」と呼ばれていますが、WikipediaによるとIPアドレスブロック、URLフィルタリング、TCPパケット中に禁止ワードが発見されたらコネクション強制遮断及び30分間の新規接続停止、DNSフィルタリング及び偽IPアドレスへのリダイレクトなどの機能によって構成されているようです。
「Wikipedia: Golden Shield Project」
複数の手法で行われるネット検閲の現状を全体的に解説するページもWikipediaにあります。 このページでは、ネット検閲が行われた事例とともに、何がブロックされるのかや、どうやって人々がネット検閲を回避しているかが述べられています。
「Wikipedia: Internet censorship in the People's Republic of China」
検索エンジンのリダイレクトに関しては、2007年にも話題になっていました。
「CNET: 中国が米国の検索エンジンを「ジャック」?--ダライ・ラマ褒章への報復か」
Danny Sullivan氏のブログ「Search Engine Land」によると、中国国内から、あるいは中国のインターネットサービスプロバイダ(ISP)を利用して、GoogleやYahoo、Microsoftの検索エンジンにアクセスしようとした多くのユーザーが、中国の検索エンジン「Baidu」(百度)にリダイレクトされたという。
通信そのものに対しての処理だけではなく、特定のアプリケーションを利用する事を強制することによる検閲も行われています。 たとえば、Skypeによるやり取り中国政府が知るために、Skypeの通信はブロックされて、公認の盗聴機能入りSkypeモドキ(Skype社の中国でのパートナーであるTOM社によるソフト)しか中国では使えないという報道もありました。
- REUTERS: Skype's China spying sparks anger
- Skype Blogs: Skype President Addresses Chinese Privacy Breach
このように、中国のネット検閲システムは様々な仕組みの集合として構築されており、DNSが偽情報を返すように仕向けるシステムも、ネット検閲の一部のようです。
個人的に、今回の事件が「中国国内の新しいシステム」によるものであるとは、あまり思えませんでした。 もしかしたら、既存のシステムに対して多少の変更を加えた新システムを実験中に経路漏れを発生させたということはあるのかも知れませんが、全体としては既存のものである気がしています。
DNSに対するネット検閲システム
中国がDNSに対して行っているネット検閲を分析した論文がネット上に公開されています。
「The Great Firewall of China(PDF), 2007年12月」
この論文は、中国でのDNS結果偽造が途中ルータで行われていることを突き止めています。 論文中で行われている検証手法は、DNS QueryのTTLを変更していくというものでした。 まず、53番(名前解決に利用されるポート番号)でのUDPパケットのTTLを徐々に増やしながら、実際には存在しないFQDNに対する正規のDNS名前解決処理を行います。 TTLが短いUDPパケットは途中ルータでTTLがゼロとなるため、ICMP Time Exceed Messsageパケットが返り、十分なTTLを持つUDPパケットに対しては「domain does not exist(NXDOMAIN)」が返ります。
次に、同じDNSに対して「禁止ワードがFQDN中に含まれ、かつ存在しないFQDN」でQueryが行われます。 この処理も正規のDNS Query同様にTTLを増やしながら行われます。
すると、禁止ワードが含まれるFQDNに対するDNS Queryは短いTTLで偽の結果を返したようです。 偽の結果は、8つのIPアドレスを含む物だったと論文に記述されています。
このように、中国のネット検閲システムは途中ルータが偽の結果を返しているようです。
今回のI DNSルートサーバ事件に関しても、恐らく、I DNSルートサーバが乗っ取られて変な結果を返すように変更されたという類いの話ではないような気がしています。 このように途中ルータでのDNSパケット偽造が行われたのではないかと、勝手に推測しています。
今回の事件概要
さて、色々と「前提」となる解説をしていたら長くなってしまいましたが、ここでやっと今回の事件発端と経過の話になります。
今回の事件は、主にdns-operationsのメーリングリスト上で発生しています。 「発生している」というよりも、「議論されている」や「話題になっている」ぐらいの表現が良いのかも知れません。
このメーリングリストでの話題が各種ニュースに拾われて広がった形だと推測されます。
ニュースの発端となったメールは以下のものです。 「チリ国内のISPからFacebook,YouTube,Twitterが見られないよ!」というものです。
「[dns-operations] Odd behaviour on one node in I root-server (facebook, youtube & twitter)」
Hi there!
A local ISP has told us that there's some strange behavior with at least one
node in i.root-servers.net (traceroute shows mostly China)
It seems that when you ask A records for facebook, youtube or twitter, you get
an IP and not the referral for .com
It doesn't happen every time, but we have confirmed this on 4 different
connectivity places (3 in Chile, one in California)
This problem has been reported to Autonomica/Netnod but I don't know if anyone
else is seeing this issue.
This is an example of what are wee seeing:
$ 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
;; QUESTION SECTION:
;www.facebook.com. IN A
;; ANSWER SECTION:
www.facebook.com. 86400 IN A 8.7.198.45
;; Query time: 444 msec
;; SERVER: 192.36.148.17#53(192.36.148.17)
;; WHEN: Wed Mar 24 14:21:54 2010
;; MSG SIZE rcvd: 66
--
Mauricio Vergara Ereche User #188365 counter.li.org
DNS Admin NIC Chile mave [@] nic [.] cl
Miraflores 222 piso 14, Santiago CHILE +56 2 9407710
Codigo Postal: 832-0198 http://www.nic.cl
これに対して、次のように「すげー!中国がDNSいじってるのは知ってたけど、それが外に漏れたのははじめてじゃね?」という返信とともに、traceroute結果が記載されたメールが送られてました。
On Wed, Mar 24, 2010 at 03:22:40PM -0300, Mauricio Vergara Ereche wrote:
> A local ISP has told us that there's some strange behavior with at least one
> node in i.root-servers.net (traceroute shows mostly China)
> It seems that when you ask A records for facebook, youtube or twitter, you get
> an IP and not the referral for .com
Wow! This is stunning. I knew that China messed with DNS internally, but not
that it leaked to the outside world. Perhaps this is what you are seeing.
Confirmed from a server in Shanghai (note the wrong checksums!)
7 x.182 (x.182) 2.601 msIcmp checksum is wrong
2.567 msIcmp checksum is wrong
2.124 ms
Icmp checksum is wrong
8 x.161 (x.161) 31.113 msIcmp checksum is wrong
9.614 msIcmp checksum is wrong
202.169 ms
9 210.22.66.185 (210.22.66.185) 2.620 ms 2.703 ms 2.613 ms
10 219.158.21.241 (219.158.21.241) 3.145 ms 3.054 ms 2.737 ms
11 219.158.3.206 (219.158.3.206) 3.269 ms 3.223 ms 2.574 ms
12 219.158.29.46 (219.158.29.46) 92.727 ms 92.685 ms 92.616 ms
13 210.130.133.69 (210.130.133.69) 102.338 ms 94.154 ms 95.960 ms
14 tky008bb00.IIJ.Net (58.138.105.177) 113.369 ms 117.653 ms 112.755 ms
15 tky009bf01.IIJ.Net (58.138.80.69) 149.537 ms tky009bf00.IIJ.Net (58.138.80.65) 97.795 ms ...
16 tky001bb10.IIJ.Net (58.138.80.22) 121.196 ms tky001bb11.IIJ.Net (58.138.80.46) 119.261 ms ...
17 tky001ix04.IIJ.Net (58.138.100.26) 109.179 ms tky001ix04.IIJ.Net (58.138.100.30) 118.512 ms ...
18 as8674.dix-ie.jp (202.249.2.180) 94.323 ms 94.045 ms 94.044 ms
19 i.root-servers.net (192.36.148.17) 94.560 ms 94.096 ms 94.035 ms
$ dig +norecurs @i.root-servers.net www.facebook.com A
; <<>> DiG 9.2.4 <<>> +norecurs @i.root-servers.net www.facebook.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14020
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.facebook.com. IN A
;; ANSWER SECTION:
www.facebook.com. 300 IN A 46.82.174.68
;; Query time: 6 msec
;; SERVER: 192.36.148.17#53(192.36.148.17)
;; WHEN: Thu Mar 25 03:40:53 2010
;; MSG SIZE rcvd: 50
This one is even more stunning:
$ dig -t soa facebook.com @i.root-servers.net
; <<>> DiG 9.2.4 <<>> -t soa facebook.com @i.root-servers.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23252
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;facebook.com. IN SOA
;; ANSWER SECTION:
facebook.com. 300 IN A 59.24.3.173
;; Query time: 7 msec
;; SERVER: 192.36.148.17#53(192.36.148.17)
;; WHEN: Thu Mar 25 03:39:27 2010
;; MSG SIZE rcvd: 46
さらに、「今まで黙ってたけど、過去に同じの見た事があるよ」といいつつ、2010年1月の観測結果をメールしている人もいました(参考)。
そのうち、「少なくとも2002年からだよ」というメールも登場します(参考)。 そのメール中で、以下の2つのURLが紹介されています。
その後、中国のRIRであるCNNICのVice President兼CTOから「CINNICはI root serverに細工はしてないし、CNNIC内ではトラフィック傍受等は一切行ってない」というメールも送信されています(参考)。
「去年この議論があったよ。それを原因としてDNSBLのSURBLが中国のネームサーバ引き上げたよ」といいつつ、2009年の「DNS replies from AS 4808」というスレッドを紹介していました。
「The dns-operations: June 2009 Archives by thread」
このメーリングリストのスレッドは、問題と関連していたI DNSルートサーバを運営していたNetNod社のCEOが「地元のホスティングプロバイダと一緒に調査中だけどIルートサーバの経路広告を停止した」というメールを送信したことで収束したようです。 このメールに「We are still investigating this issue together with the local hosting provider and their upstreams.」とあるのですが、「local hosting provider」の役割が気になるところです。 I DNSルートサーバの実際の運用を行っていたのはNetNod/Autonomicaなのでしょうか?それとも現地の事業者に委託していたのでしょうか?
I DNSルートサーバはどうなったのか?
さて、最後に、I DNSルートサーバがどうなったのかに関しての推測です。
www.root-servers.orgを見ると、中国国内には3つのDNSルートサーバがあるようです。 FとIとJです。 どれもローカルなDNSルートサーバなので、中国国内でしか利用できない筈です。
dns-operationsのメーリングリストでNetNodのCEOが「地元のホスティング事業者や、その上流と一緒に調査中」と述べていますが、その中で、関連するI DNSルートサーバのエニーキャスト経路広告を停止したとも述べています。
「DNSルートサーバが中国国内で停止」という表現だけを見ると、おおごとのようなイメージを受けますが、実際には3つあるDNSルートサーバの一つに関するエニーキャスト経路広告を停止したという話であり、しかもその「停止範囲」は明言されていません。 もしかすると、中国国外に出ないように停止しただけなのかも知れません。
現時点では真相が不明ではありますが、今回の事件は、恐らく中国国内のユーザに影響を与えるものでは無い気がします。 仮に、Autonomica(実際にI root serversを運用しているのはNetNod子会社のAutonomica)のI DNSルートサーバが完全停止したとしても、JとFの2つも北京にあるわけですし。
中国国内ユーザにとっては日常であるネット検閲システムの一部を、チリのユーザが体験できただけという事件ではないでしょうか。
さらに、そもそも今回の「I DNSルートサーバであると思われるIPアドレス」が「本当にI DNSルートサーバであるか?」も良くわかっていないという考え方すらあります。 エニーキャストや途中ルータでの検閲が組合わさった複雑なネットワーク構成を、海の向こうから完璧に推測するのがどこまで可能なのかという問題を含めて、今回の件は色々複雑な事件ではないかと思われます。
最後に
結局、ニュースというのは、その時々でコンテキストに合っているかどうかや、そのタイミングでキャッチーであるかどうかが非常に大きな意味を持つのではないかと思った今日この頃です。
でも、これをキッカケとして色々調べられたのは面白かったです。
ニュース記事一覧
今回、私が参考にしたニュース記事一覧です。
- CNET News InSecurity Complex: Web traffic redirected to China in mystery mix-up
- Neowin.net: China's censorship firewall invades foreign systems
- tom's hardware: DNS Problem Brings Great Firewall of China Global
- THINQ.co.uk: Jitters as China firewall leaks
- PCWorld: China's Great Firewall Spreads Overseas
- PC Pro: YouTube, Facebook and Twitter "redirected to China"
- CSO Security And Risk: Chile NIC explains Great Firewall incident
- Fast Company: China Behind Yesterday's YouTube, Facebook, Twitter Outage
- TG Daily: Great Firewall of China goes global in DNS muddle
- ubergizmo: YouTube, Facebook And Twitter Traffic Redirected To China?
追記
最近のエントリ
- 日本のIPv6採用状況が50%を超えている件について
- 「ピアリング戦記」の英訳版EPUBを無料配布します!
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
過去記事