DNS問い合わせの可視化

DNS問い合わせの可視化

全体像

最近、データをまとめたり可視化したりしてその性質を調べる探索的データ分析()にはまっています。と、同時にネットワーク分析にもちょっと手を出しており、その2つの派生物としてドメイン名問い合わせの結果を可視化してみました。

これを読んでいる人にはもはや説明の必要はないと思いますが、一応書いておくと、世の中のwww.google.comやwww.amazon.co.jpのようなドメイン名はサーバの場所を直接示しているわけではなく、「この名前を持っているサーバのIPアドレスはなんですか?」というのをDNSサーバという別のサーバに問い合わせることで目的のサーバのIPアドレスを教えてもらい、その後目的のサーバへ接続します。以前は正引き(ドメイン名からIPアドレスを問い合わせる)と逆引き(IPアドレスからドメイン名を問い合わせる)が対称構造になるように設定するのが主流でしたが、最近は負荷軽減などのテクニックが複雑化し、単純ではない構造になっており利用者からは実態がよくわからなくなっています。

そこでDNSの問い合わせとその結果から何か見えるものがあるのではと思い、試しに可視化してみました。可視化には自宅のネットワークを24時間監視したデータを使いました。問い合わせ応答数(全レコード数)は75,098件、トラフィック分析には自作ツール、可視化はベタにgraphvizです。今どき感をだすためにJavaScriptの描画ライブラリも検討しましたが、arbor.jsとかノード数が数百に達するとあっというまにブラウザが真っ赤になって憤死するので断念しました。

windows.microsoft.comの例

まずは一番わかりやすいケースです。黄色ノードがCNAMEの問い合わせドメイン名(ブラウザなどで最初に問い合わせたドメイン名)、黄色から点線でつながっている赤ノードがCNAMEの問い合わせ結果、そして緑ノードが実際のIPアドレスになります。ここでは、

  1. 何かのプログラムがwindows.microsoft.comのIPアドレスを問い合わせた
  2. windows.microsoft.comの実態はorigin.windows.microsoft.com.akadns.netというホストですよ、と教えられた
  3. さらにorigin.windows.microsoft.com.akadns.netのIPアドレスを問い合わせてみた
  4. origin.windows.microsoft.com.akadns.netのIPアドレスは65.52.103.234ですよ、と教えられた
  5. 何かのプログラムは65.52.103.234に接続する

という一連の流れが起きたと考えられます。(かなりざっくりですがそこはご愛嬌で)

ad.yahoo.co.jpの例

次は一つのドメイン名に対して、複数のIPアドレスが応答されている場合です。ここでは一度にこの応答が返されたのか順次返されたのかまでは追いかけていませんが、複数の宛先サーバを用意することで負荷を分散させるためによく使われている手法かと思います。

nikkei.co.jpの例

逆のケースも有ります。複数のドメイン名に対して一つのIPアドレスだけが割り当てられている場合です。これは複数のサービスがあるものの負荷があまり大きくないので、一つのサーバに役割を兼任させているのではないかと推測されます。

dropbox.comの例

そろそろごつい感じの例も見て行きたいと思います。Dropboxでは問い合わせる際にはclientXX.dropbox.comというドメイン名で最初に問い合わせますが、これが一度client.dropbox.comに集約され、client.v.dropbox.comに向けられた上で、そこから多くのIPアドレスを返してきています。これは後々の事を考えて最初の問い合わせ元を分散させておいたのかな…と妄想しますが、実際のところどうなのかはよくわかりません。あとさりげなくclient-lb.dropbox.comというロードバランサーらしきものも見えてはいます。

couldfront.netの例

徐々に激しくなってきたこちらはcloudfront.net関連です。AmazonがAWSで提供しているコンテンツ配信ネットワークになります。いくつかのサイト(nikkei.comtogetter.comalc.co.jpevernote.com)が入口となっていますが、実態となるIPアドレスはとても数が多く、さらにドメイン名から入り乱れてIPアドレスへつながっていることから、複数サイト間をまたがっている内部構造になっていることが伺えます。

google関連

そろそろ何が起きているのかよくわからなくなってきました。こちらはgoogleに関連したドメイン名(の一部)になっています。これだけでgoogleの海千山千なシステムを読み解くのは難しいですが、少なくともGoogle内部の複数のサービス(youtube、google-analysis、google map)などが同じサーバをまたがっていることがわかります。そのため、多くのサービスは共通のミドルウェアのようなインフラの上に相乗りしている状態か、あるいはこのIPアドレスは全部ロードバランサみたいな、ガワだけ見えている状態なのかもしれません。

akanai関連。ネットは広大だわ

トリを飾るのはインターネット界の裏に君臨するAkamaiです。見よ、この圧倒的なカオス! …というほどでもないかもしれませんが、他のgoogleやamazonといった大規模サイトとくらべても、内部構造が複雑になっていることが伺えます。Akamaiは名前こそあまり表に出てきませんが、多数のWebサイト・サービスのCDN(Contents Delivery Network)を世界最大規模で請け負っている企業です。(詳しい解説はぜひこちらを御覧ください)

黄色いノードが一番最初の問い合わせドメイン名なので、ざっくり言うと黄色いノードの多さにあわせていろいろなサービスが乗っかっているのがわかります。また、どこかのドメイン名に集約されてから一様に分配されるというわけではなく、複数の全く違う入り口から一つのIPアドレスにたどり着いているケースがとても多いようです。これはどのISPを使っているかによって見え方が違うらしいのですが、例えばこの例ではリクルートと思われるドメイン名とLinkedInと思われるドメイン名が一つのIPアドレスに紐付いていました。

akamai-apple島

また、あくまで推測ですが、同じAkamaiでもApple専用の島というものがあるようです。これらは他のWebサービスとは独立した専用のサーバ郡がわりあてられているようです。中心部が完全に潰れていますが、それぞれCNAMEの解決先はus-courier.push-apple.com.akadns.net.service1.ess.apple.com.akadns.net.などとなっており、そこから多数のIPアドレスに分配されています。us-courier.push-apple.com.akadns.net.にいたっては440個のIPアドレスと紐付けられているのを観測しました。

フルサイズの絵はこちらからダウンロードできますが、37.5MBのPNGという貧弱なPCだと泡を吹きそうになるサイズとなっているで、閲覧の際は十分ご注意ください。

参考文献

Comments