Google Public DNS解説と個人的妄想

2009/12/7-1

前回書いたGoogle Public DNSに関する記事があまりに説明不足なので、補足文章を書く事にしました。

今回のGoogle Public DNSは、単なるオープンDNSサービスでは留まらず滅茶苦茶凄過ぎていて、ある意味インターネット全体のありかたを変えてしまう可能性さえあると個人的には思っています。何故そう思っているかを含めて、色々書いてみました。

以下の文章は多くが公式発表からの引用ではなく、その他の外部観測情報を元にした推測や個人的な妄想が入り交じっているので、内容に関しては各自で考えて判断をお願いします。

Google Public DNSでウェブ閲覧が高速化するの？

とりあえず、背景や技術はどうでも良いから「高速化するかしないかだけ知りたい」という方々が非常に多い気がするので、個人的なGoogle Public DNS高速化に関しての考えを最初に書きます。

「Google Public DNSを使うとウェブ表示が早くなる人も居れば、逆に遅くなる人も居る」というのが私の考えです。 (実際には、この「どのDNSが早いか？」という問いに対する広く一般的な回答を得るための測定は非常に困難だと思います)

では、まず、どういう人が「早くなる」のかですが、以下のような人がGoogle Public DNSを使うと早くなると推測しています。

現在使っているDNSキャッシュサーバがタコ
海外のウェブサイトを多く閲覧する人
あまりメジャーではないウェブサイトを良く閲覧する人

逆に、Google Public DNSを使うと「遅くなる」と思われる方々です。

日本国内でメジャーなウェブサイトを中心に見ている人
皆が注目しているニュース等以外はウェブ上でほとんど見ない人

例えば、日本国内の大手ISPによって運営されているDNSキャッシュサーバの質は非常に高いと思われます。そのため「日本国内で多くの人が問い合わせるドメイン名(FQDN)に関しては、日本国内のDNSキャッシュサーバの方が早いことが多い」と個人的に推測しています。

では、どういった点でGoogle Public DNSが有利で、何故それが可能なのかに関しての私の推測(or妄想)を次に述べます。

背景

Google Public DNSを知るには、現状のGoogleのバックボーンネットワークの「強さ」を知る必要があると思われます。 Google Public DNSが今までのオープンDNSサービスと比べて圧倒的なのは、既存のGoogleバックボーンネットワークの存在が非常に大きいのではないでしょうか。

現在、Googleは「インターネットのどこにでもいる」という形になっていると推測しています。この「どこにでもいる」というのは、「様々なネットワークと隣接した状態にある」という意味です。

インターネットの語源は「Inter-net」であり、ネットワークが相互接続されたネットワークです。各ネットワークは「管理主体」を元にAS(Autonomous System)という単位に別れて相互接続しています。ネットワーク同士はBGP(Border Gateway Protocol)というプロトコルで相互接続されており、Googleも独自のAS番号を取得して様々なASと接続しています(参考：BGPを解説してみた)。以後、ASという単語を使って説明しますが、ASとはISPやGoogleなどの組織が運営するネットワークだと思って下さい(MicrosoftやAppleもASを持っています)。

インターネットでは、遠くのネットワーク(AS)に行くために複数のネットワーク(AS)にパケットをバケツリレー的に転送してもらうことで、遠く離れた機器同士が通信できるように設計されています。そのため、AS的に「隣に居ない状態」であっても、相互に通信ができる仕組みになっています。

しかし、経由するASが増えるということは、経由するルータなどの機器や光ファイバケーブルを多く経由することを意味します。通信する距離や、経由する機器が増えれば増えるほど、通信速度は低下します。それを避けるために、AS同士は「ピアリング」という形でネットワークを接続します。ピアリングとは「AS的に隣になりましょう」ということです。ピアリングを行って「隣同士」になれば、複数のASを経由するよりも通信速度が早くなります（その他政治的な側面も強いと思われますが、そこは今回は割愛）。

そして、恐らく日本の大手ISPのほとんどはGoogleとピアリングしています。日本の大手ISPのほとんどは「Googleと直接隣同士」なのだろうと思います。さらに、日本に限らず、ヨーロッパやその他地域においてもGoogleは「世界中に居る」状態だと思われます。多少語弊がある図ですが、こんな感じです。

自分が居るISPがGoogleのお隣さんになっているかどうかを確認するのは非常に簡単です。例えば、www.google.co.jpにtraceroute(windowsだとtracertコマンド)してみて下さい。その結果出て来るIPアドレスが所属しているAS番号を見て行くと、隣かどうかがわかります。 IPアドレスからAS番号を確認するにはwww.radb.netなどをご利用下さい。

例えば、アメリカのAbovenetとGoogle Public DNSの8.8.8.8がAS的に「隣」であるかどうかをtracerouteの結果から見てみます。


Abovenet(アメリカ)

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  so-2-1-0.mpr2.ams5.nl.above.net (64.125.31.254)  0.706 ms  0.587 ms  0.564 ms
 2  so-2-0-0.mpr1.lhr2.uk.above.net (64.125.27.177)  6.351 ms  7.230 ms  7.294 ms
 3  xe-1-1-0.mpr1.lhr1.uk.above.net (64.125.27.150)  5.981 ms  58.400 ms  13.661 ms
 4  72.14.217.93 (72.14.217.93)  108.082 ms  6.054 ms  6.133 ms
 5  209.85.252.76 (209.85.252.76)  6.284 ms  6.355 ms  6.277 ms
 6  72.14.232.134 (72.14.232.134)  13.153 ms 66.249.95.170 (66.249.95.170)  14.117 ms 72.14.232.134 (72.14.232.134)  13.079 ms
 7  209.85.251.231 (209.85.251.231)  13.231 ms  13.222 ms 72.14.236.191 (72.14.236.191)  36.229 ms
 8  209.85.243.73 (209.85.243.73)  13.376 ms 209.85.243.81 (209.85.243.81)  18.063 ms 209.85.243.73 (209.85.243.73)  28.517 ms
 9  google-public-dns-a.google.com (8.8.8.8)  12.375 ms  14.095 ms  16.414 ms

上記結果を見ると、3番目の結果である64.125.27.150までは逆引き結果が「above.net」になっています。一方で、3番目の次の結果である4番目のアドレス72.14.217.93は、Googleを示すAS15169です。この結果から、3番目のルータと4番目のルータがAbovenetとGoogleの境界であることがわかります。さらに、1,2番目はAbovenetで、5～9番目はGoogleのASです。このような感じで、自分のISPからtracerouteした結果を見ると「Googleが隣にいるかどうか」がわかります。

世界で非常に多くのASとピアリングしている組織としては、Tier1と呼ばれる世界的規模のキャリアか、AkamaiかGoogleが代表的だと思われます。そして、Googleは今や世界のトラフィックの約10％を生成し(YouTube含む)、バックボーンとしてはいくつかのTier1キャリアよりも強力なものを保持しているという、インターネットインフラ界の「巨人」だと推測されます。 NANOG47でのAbor Networksプレゼンでは、世界第3位とされていました。 (ATLAS 10 2009 3位は、AT&TやNTTより上です。参考：NANOG47資料解説→「インターネットの形を変えて行くGoogle,Facebook,Akamai...」）

なお、余談ではありますが、これはバックボーンネットワークの話であり、アクセス回線の話ではありません。アクセス回線まわりの話はネット中立性(Network Neutrality)の議論が絡んで来ると思いますが、その話はここでは割愛します。

anycast

Google Public DNSの話題の中で「anycast(エニーキャスト)」という単語が度々出ており「anycastって何？」と思った方々も多いと思います。次は、anycastとは何かに関して説明します。

anycastとは、その名の通り「どれでもいいから近くに行く」というものです。具体的な手法としては「同じIPアドレスを持った機器が世界中に複数ある」という状態が造り出されています。 anycastは、技術そのものとしては結構前からある技術です。例えば、長野オリンピックの時にもWebサーバの負荷分散を行うためにanycast技術が利用されていました。また、Root DNSはanycastによって運営されています(参考：RFC3258)。

かなり嘘が混じっていると思いますが、ざっと図にするとこんな感じです。 BGPを通じて相手を選んで「8.8.8.0/24はココだよ！」と言うのですが、その言い方(言う相手の選び方)や、ネットワーク上での機器の配置で工夫をしているのだと予想しています。

このanycastが実現できることと「Googleがそこら中に居る」というのは、恐らく無関係ではありません。

DNSとは何か？

Google Public DNSの速度を知るには、そもそもDNSとはどういう仕組みで動いているのかも知る必要があります。

次の例では、ユーザが「www.example.com」というWebサイトを見ようとしたときの動作です。まず、ユーザのノートPCには、DNSクライアントが入っています。そのDNSクライアントは「www.example.com」という名前に対応するIPアドレスが、自分のキャッシュの中に入っているかどうかを調べます。ノートPCの中のDNSクライアントが過去に「www.example.com」の名前解決をした事が無く(過去に名前解決した結果のキャッシュがタイムアウトしている場合もあり)、キャッシュに「www.example.com」の名前解決済みIPアドレスが無い場合、DNSクライアントはDNSキャッシュサーバに「www.example.com」の名前解決を依頼します。 DNSキャッシュサーバは、「www.example.com」の名前解決結果を、ノートPCの中のDNSクライアントに伝えます。

さて、上記例はユーザ視点でのDNS動作です。

しかし、実際にはもう少し複雑です。次は、DNSキャッシュサーバが「www.example.com」の名前解決結果キャッシュを持ってない場合を考えます。

まず、最初にDNSクライアントがDNSキャッシュサーバに問い合わせを行うのは同じです。 DNSキャッシュサーバは、www.example.comに対応するキャッシュを保持していないので、外部のDNSに問い合わせを行ってwww.example.comの名前解決を試みます。

DNSキャッシュサーバは、まず「www.example.comを教えて！」とルートDNSに問い合わせます(2)。すると、ルートDNSは「.comに聞いて！」と応えます(3)。

次に、.comのDNSに「www.example.comを教えて！」と問い合わせます(4)。すると.comのDNSは「example.comに聞いて！」と応えます(5)。

さらに、今度はexample.comのDNSに「www.example.comを教えて！」と問い合わせます(6)。するとexample.comのDNSは、FQDNに対応するIPアドレスを返してくれます(7)。

www.example.comのIPアドレスを得たDNSキャッシュサーバは、DNSクライアントに結果を通知します(8)。

このようにDNSキャッシュサーバにキャッシュが無いと、裏で様々な問い合わせが発生して応答に時間がかかります。

最終的に得られた結果をDNSキャッシュサーバは、ノートPCのDNSクライアントに伝えます。

実際には、通常運用されているDNSキャッシュサーバは「.com」ぐらい一般的なエントリのキャッシュは保持していないということが、ほとんどありません。しかし、例えば、旅行関連の「.travel」や、博物館の「.museum」など、ほとんど使われていないような名前だとルートDNSからの名前解決になるのかも知れません。

という感じで、DNSキャッシュサーバにキャッシュが無い場合には、DNSクライアントが知らないところで複数の問い合わせが行われています。このように複数の問い合わせが必要となるため、速度に関して考える場合にはDNSキャッシュがヒットするかしないかは非常に大きな問題です。

それを踏まえたうえでGoogle Public DNSとISP DNS比較

例えば、私の環境ではISPのキャッシュサーバでwww.hatena.ne.jpを問い合わせた結果は9msecで返って来ます。一方で、www.ietf.orgを問い合わせると311msecかかりました。しかし、www.ietf.orgの問い合わせ２回目の時には、先ほどのキャッシュがDNSキャッシュサーバに入っているので9msecで返ってきました。

Google Public DNSの場合、www.ietf.orgも、www.hatena.ne.jpも、60msec弱ぐらいで返答が返ってきます。今のところ、マイナーなFQDNか、そもそも存在しない事がわかっているFQDN以外では大抵同じぐらいの速度になっています。

広い範囲で安定的にキャッシュミスしないGoogle Public DNSと、地元で距離が近くて返答が早いけどGoogle Public DNSほどのキャッシュのバリエーションは無いISP DNSキャッシュサーバという違いがありそうです。

ISPが用意しているDNSキャッシュサーバがGoogle Public DNSよりも容量が少ないからといって使い物にならないわけではありません。現に、今まで特に不自由はせずに名前解決が出来ていたと思います。 ISPが用意しているDNSキャッシュサーバのキャッシュには、「そのDNSキャッシュサーバを利用している人々の残したキャッシュ」が残っています。ということは、「そのDNSキャッシュサーバを使っている人々がよく見るWebサイトの名前解決に関しては、ISPのDNSキャッシュサーバの方が早い」という場合が多そうです。

しかし、例えば海外のブログやニュースを多く見る人が、そのDNSキャッシュサーバに少ない場合、それらのFQDNの名前解決用のキャッシュがISPのDNSキャッシュサーバに残っていない可能性が高くなります。すると、そういったFQDNを解決するには数百msecが必要となり、Google Public DNSを使った方が、それらの名前解決に関しては早くなるという場合もありそうです。

早いかどうかをどうやって測定すればいいの？？？

このように、DNSキャッシュがヒットするかミスするかが大きな要素であり、Google Public DNSは、ローカルISPが提供するDNSキャッシュサーバよりもキャッシュミスが少ないという点がウリなのだろうと推測しています。

そのため、単にGoogle Public DNSのanycast IPアドレスとのRTT(Round Trip Time)を計測しても、実際の用途でのGoogle Public DNSの効果がわからないというのが測定の難しい所です。

さらに、測定のためにGoogle Public DNSに対して名前解決を一度Queryしてしまうと、そのキャッシュが出来上がってしまうので、1度目の測定結果と2度目の測定結果が全く異なる物になる可能性が高かったり、ISP側のDNSキャッシュサーバで自分と同じ名前解決を行いたい人が居るか居ないかで存在するキャッシュの内容が異なるという点も測定を困難にしていると思われます。個人的には、広く一般的に「Google Public DNSが既存ISP DNSキャッシュサーバよりも早いか遅いか」という結論を出すための測定方法は思いつきません。

とはいえ、RTTも重要な要素の一つではあります。現時点ではGoogle Public DNSは太平洋を超えない国外のどこかにありそうだと噂されていますが、そのうち日本国内にもGoogleデータセンターが構築される可能性があります。昨年Googleが日米間の海底ケーブル建設に乗り出したニュースは記憶に新しいと思います。 (参考「Google:【報道資料】急増する帯域幅需要に対応して、国際的な共同体が、日本と米国を結ぶ新しいケーブルシステムの共同建設を発表」)

Googleデータセンターが日本国内に構築されたときに、Google Public DNSの速度は今より上昇するのかも知れません。

DNSとCDN

Googleが世界中のユーザに快適で高速なWeb体験を提供するために、恐らくanycastが既に利用され続けています。さらに、窓口のWebサービスだけではなく、世界規模の巨大な自社ネットワークの裏でコンテンツを扱うためのCDN(Contents Distribution Network)も構築されているはずです。

Google Public DNSは、恐らく既存のGoogle Webサイト構築用のCDN技術を、DNSキャッシュサーバに活かしたものです。

例えば、DNSの名前解決結果をPrefetchするという説明が書いてありますが、これはWebをクロールするロボットのようなものだと思います。 WebよりもDNSの方が楽だろうと思える点もいくつかあります。

まず、Webよりもデータのエントリ数が劇的に少ないだろうと推測できます。 WebのURLは、ある特定のFQDN(ホスト名)の中に多数のファイル(もしくはパス)が存在していますが、DNSの場合はFQDNだけです(MX,NS,その他などもあるのですが、とりあえずそこら辺は割愛)。エントリが少ないということは、必要な記憶用機器もWebよりも少なくて済みそうです。

さらに、Webよりも劇的にキャッシュを活用しやすいのが「TTL(Time To Live,有効期限)」があらかじめ明記されている点です。 Webであれば「Webサーバ上のコンテンツがいつ更新されているのか予測がつかない」ので、Google側で勝手にコンテンツを代理で出す事は出来ません（Webコンテンツの場合は著作権的問題もありますが、ここではそれは範疇外）。

一方、各種DNSの回答結果にはTTLが付属しています。「この名前解決結果は○○秒後までは再度問い合わせなくてもキャッシュで代わりに回答してもいいですよ！」というのがプロトコル内に含まれているので、TTLで規定された時間内であればDNSに問い合わせせずにキャッシュを見るだけで勝手に回答しても良いことになっています。 Google Public DNSのPrefetchというのは、このTTLが切れる前に新しいQueryを自分で出してしまってDNSキャッシュを更新してしまうというものです。

Google Public DNSは非常に多くの名前をあらかじめ解決してキャッシュとして大量に保存してあるので、キャッシュミスが発生しにくくなるのだろうと思います。例えば、全世界の全てのDNSエントリ(Webページがindexされているもの)の最新情報を常にprefetch済みにしておけば、キャッシュミスが発生するISPのローカルDNSキャッシュサーバよりも早くなるというものなのだろうと思います。既存のGoogle Public DNSが、全世界のあらゆるエントリを常に最新に保ち続けているかどうかはわかりませんが、あらゆるURLのキャッシュを保持し続けられる組織であれば、世界中のDNSによる名前解決結果は保持できるのかも知れません。

Web用のRobotと、連動しているのかしていないのかなどは良くわかりませんが、連動していれば、そもそも誰もGoogle Public DNSに問い合わせた事もないエントリに関してもDNSキャッシュを最新に保ち続ける事ができそうです。

どこまでGoogle Public DNSは普及するのか？

Google Public DNSはどこまで普及するのでしょうか？個人的には爆発的に普及しそうだと考えています。

例えば、来月号以降の雑誌で「Google Public DNSで爆速ブラウジングのマル秘テクニック」などの特集が組まれたりするだろうと思うので、まずは出だしとしては、それで普及しそうです。あまり技術には興味がないユーザが、あまり考えずに一度設定を行って、その後は8.8.8.8が維持され続けるというのもありそうです。

また、日本国内では最速では無いにしても、安定してキャッシュミスしないのであれば、全体的には高速化したと感じさせやすいのと、8.8.8.8という覚えやすい数値とISPによる覚えにくい数値で、どちらが選ばれるかと言えば、恐らく前者だろうと思います。 ISP側からの書類が発見できなくて、DNSキャッシュサーバのIPアドレスがわからなければ何も考えずに8.8.8.8と入力するというのも増えそうです。

さらに、市販されている家庭用のSOHOルータ(ブロードバンドルータ)のデフォルト設定に組み込まれたりすると、さらに爆発的に普及すると思われます。各ユーザがGoogle Public DNSを使っているかどうかを認識すらせずに使う状態が出来上がります。

今まで、どこか特定の組織がDNSキャッシュサーバを広く提供してユーザを集めるという事を行ってきませんでした。というよりも、できませんでした。 OpenDNSなどがありましたが、地理的に離れると速度が低下するなどの課題があり、さほど普及していたとは思えません。

今回のGoogle Public DNSは、膨大なDNSキャッシュを管理できて、anycastも既存インフラで運用可能なGoogleが行うからこそ、凄過ぎるのだろうと思います。

DNSを活用した他者CDNとの相性

さて、Google Public DNSの速度問題ですが、返答速度だけが「速度」ではありません。返答された結果によって、その後、実際のコンテンツを取得するための通信速度が変わる場合もあります。それには、コンテンツを保持している組織からのDNS回答が最寄りのミラーを示している必要がありますが、Google Public DNSを利用している場合、DNSでの名前解決結果が現時点では最適では無い回答を返す場合もありそうです。

例えば、私の家からAkamaiのCDNサービスを購入している「www.asahi.com」の名前解決を行うと、異なる結果が返ってきます。それぞれに対してtracerouteを行うと、自宅からの結果は8ホップでRTTは28msecぐらいだったのに対して、Google Public DNSを用いた結果だと14ホップでRTTが90msecになりました。 Google Public DNSでの14ホップですが、AS的には3ホップ目になっていました。

自宅からのISP DNSキャッシュサーバからのAkamai結果は、私の自宅が含まれるASの隣のAS(恐らく国内)でしたが、Google Public DNS側の結果を見るとtracerouteでの途中経路の逆引きにnrt→hkgという部分があるので成田→香港と行ってそうです。 RTTから見ても香港側に行ってそうな気がします。

Google Public DNSが他のDNSコンテンツサーバに問い合わせを行う時のIPアドレスは8.8.8.8では無いようです。自前DNSを運用した状態で、存在しないFQDNで8.8.8.8にQueryを出してみると、自前DNSへGoogle Public DNSからの問い合わせが来るのでわかります。このときのGoogle Public DNSからのDNS Queryを送信してくるIPアドレス送信元は地域によって異なっているのかも知れません。

Akamaiが正しくGEOロケーションをやっていて、Google Public DNSのデータセンターがアジア側の「海外」にあるのであれば、ある意味、Akamaiシステムとしてはあるべき姿なのかも知れません。ということで、現時点ではGoogle Public DNSの返すIPアドレスが、AkamaiなどのDNSを活用したCDNとの相性によって、日本国内においては最適ではない可能性もありそうです。

「www.symantec.com」も試してみましたが、結果は同じでした。他はあまり深く試していないので、全てにおいてこのような結果になるかどうかはわかりません。

参考：みんなが知らずに使ってるAkamai

Google == インターネットへ？？？

このGoogle Public DNSの発表を知って調べてみた結果としての個人的な感想としては、今回のGoogle Public DNSはインターネットの概念そのものを変えかねないと思いました。

個人的に、どれぐらい衝撃的な内容だと感じたかですが、ここにポルナレフの「あ...ありのまま今　起こった事を話すぜ...(中略) もっと恐ろしいものの片鱗を味わったぜ...」というアスキーアートを貼付けて違和感がないだろうというぐらいです。

今後、時間をかけてGoogle Public DNSは普及して行くと個人的に予想しています。そして、例えばGoogle Public DNSユーザが世界の数十パーセントに達したとき、何が起きるのか予想ができません。今や、インターネットとはIPアドレスではなく「名前」です。その「名前」に関しての制御権は、今まで世界各地のDNS権威サーバによって分散管理されていました。 DNSの分散管理の仕組みは、広大なインターネットをスケーラブルに運用する代名詞のようなものでさえありました。政府などとは独立して名前等を管理するICANNも「運用」や「政策」という意味でのインターネットの分散管理の象徴でした(アメリカ政府とICANNの関係に関しては割愛)。

それは、非常に大きなシェアを持った単一の組織が居ないという前提の元に今までは成り立っていたのだと、個人的に思います。

そこへ、例えば、世界の数十パーセントのユーザを抱える単一組織が登場すると、どうなるのでしょうか？「オレはこうやっちゃうもんねー。うちのユーザにはこの機能を提供するよ」と言われると、ある程度はそれに従わざるを得ない状況が生まれそうです。

例えば、「Google Public DNSを使ってもらおうキャンペーン」と言いながら、「Google Public DNSを使っている人だけが解決出来る名前」というサービスを開始したとき、DNSの名前管理のありかたが根底から変わる可能性すらあります。

Google Public DNSのユーザが莫大な増加をするということは、ある意味Googleがルートネームサーバを含めた全ての名前解決に影響を与えられることに近いのではないかと思います。

技術的には、ルートネームサーバは誰でも運用可能です。「Alternate Root」という「勝手にルートサーバ」な方々が昔から居て、話題にはなっていましたが、実はさほど大きな問題へは発展していません。これは、Alternate Rootのユーザが少ないからです。この「ユーザを集める」というのがインターネットの大きな障壁だと思います。インターネットは、「技術的には世界を変えてしまうような施策を誰でも可能な部分がいくつかあるけど、作ったとしてもユーザが来てくれないから今の形が保たれている」という側面があるのではないでしょうか。

ルートネームサーバではなくTLD(Top Level Domain)ですが、2003年に.netや.comを運営するVeriSignが「存在しないドメイン名を問い合わせした時の挙動」として、自分のサーバアドレスを返すという事件がありました。存在しない名前を要求した相手に自分のサーバを返すという我田引水を行ったわけですが、 .netや.comなどのTLDを管理しているVeriSignだからこそ出来たことです。このとき、様々な反発が発生し、VeriSignはリダイレクトをやめました。例えば、Google Public DNSユーザが非常に多くなり、Googleが何か「新しいこと」をやろうとすると、どうようの騒動に発展する可能性はありそうです。

参考：ICANN | Verisign's Wildcard Service Deployment

ネームサーバはインターネットの中で通信に対して柔軟性を提供している面もあります。例えば、次世代インターネット系の研究の中には「重要なのはURLじゃなくてコンテンツだよね！だから"機器の場所"に紐づいたFQDNを含むURLって変だよね！コンテンツIDでデータだけ流通するのがいいよ！」という系統の提案もあります。でも、よく見ると最初のデプロイとしてはDNSを活用して独自の名前管理をするという実装方法だったりします。

何が言いたいかというと、「ある程度自由に変更を反映できる世界的なDNSを持っていると、インターネットアーキテクチャそのものにメスを入れたくなる誘惑が強くなるのではないか？」と思うということです。例えば、世界の半分のユーザを抱えるDNSキャッシュサーバが生まれたとき、「インターネットとは何か？」という問いに対する回答は今とは変わっているのかも知れないとさえ思います。

まあ、気にし過ぎなのかも知れませんが。。。

自前の発電施設や国際ファイバケーブルを物理的に持っていて(telegraph記事, NYTimes記事)、ランキングによっては世界第3位のバックボーンネットワークを持っている、インターネットインフラ界の巨人が「世界中の皆様！私がDNSキャッシュサーバを皆様のために！」という世界が来たんですね。本当に凄いことだと思います。

8.8.8.8の裏側を妄想

以下、おまけです。

dig @8.8.8.8 NSをやっていると、結果が大文字になったり小文字になったりすることがあります。また、何故か急にTTLの値が増える事があります。

これは、きっと、8.8.8.8というアドレスの向こうに複数のDNSが存在していて、ロードバランシングをしているものと思われます。



> dig @8.8.8.8 NS

; <<>> DiG 9.3.4-P1 <<>> @8.8.8.8 NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52886
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			209154	IN	NS	E.ROOT-SERVERS.NET.
.			209154	IN	NS	I.ROOT-SERVERS.NET.
.			209154	IN	NS	G.ROOT-SERVERS.NET.
.			209154	IN	NS	F.ROOT-SERVERS.NET.
.			209154	IN	NS	H.ROOT-SERVERS.NET.
.			209154	IN	NS	D.ROOT-SERVERS.NET.
.			209154	IN	NS	M.ROOT-SERVERS.NET.
.			209154	IN	NS	A.ROOT-SERVERS.NET.
.			209154	IN	NS	C.ROOT-SERVERS.NET.
.			209154	IN	NS	J.ROOT-SERVERS.NET.
.			209154	IN	NS	L.ROOT-SERVERS.NET.
.			209154	IN	NS	B.ROOT-SERVERS.NET.
.			209154	IN	NS	K.ROOT-SERVERS.NET.

;; Query time: 45 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec  4 16:41:47 2009
;; MSG SIZE  rcvd: 228



> dig @8.8.8.8 NS

; <<>> DiG 9.3.4-P1 <<>> @8.8.8.8 NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30905
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			211693	IN	NS	a.root-servers.net.
.			211693	IN	NS	b.root-servers.net.
.			211693	IN	NS	c.root-servers.net.
.			211693	IN	NS	d.root-servers.net.
.			211693	IN	NS	e.root-servers.net.
.			211693	IN	NS	f.root-servers.net.
.			211693	IN	NS	g.root-servers.net.
.			211693	IN	NS	h.root-servers.net.
.			211693	IN	NS	i.root-servers.net.
.			211693	IN	NS	j.root-servers.net.
.			211693	IN	NS	k.root-servers.net.
.			211693	IN	NS	l.root-servers.net.
.			211693	IN	NS	m.root-servers.net.

;; Query time: 45 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec  4 16:41:50 2009
;; MSG SIZE  rcvd: 228

あと、一つ気になったのが、実際にDNSキャッシュをどこまで共有できているのかも疑問な部分もあります。例えば、マイナーなFQDNを問い合わせて、TTLの範囲内で数十分経過しないうちに再度digを連発してみると、何度かはキャッシュが無いような結果になります。また、良く考えると、そもそもTTLにバリエーションがあるというのは、キャッシュを全体で共有出来ていない事を示している気がします。ここら辺は、様々な方々が色々試して解析が進んで行くのだろうと思いました。

過去記事

過去記事一覧

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