Speedup your browsing experience.
インターネット閲覧速度向上
http://code.google.com/intl/ja/speed/public-dns/docs/performance.html
インターネットに接続する際には、前のページにてDNSサーバーに「ドメイン名のIPアドレスを問い合わせる」(名前解決をする)ことで、インターネット上のどのコンピューターに接続をすれば良いのかが分かり、結果としてWebサイトを見れることを説明させて頂きました。
家族や友人の電話番号をメモに書いたり暗記したりして、電話をする度にメモをみたり思い出したりしていたものを
「電話帳」のおかげで名前で検索できるようになった
と同じく
DNSのおかげで人は
ドメイン名だけ覚えていればドメイン名を指定するだけで
簡単にしかも以前よりも素早く
希望のコンピューターにアクセスできるようになりました
このDNSでの名前解決をより早くすれば、Web閲覧速度がもっと向上します。
ドメインの情報は1つのDNSサーバーには収められていません
電話帳で言うところのグループ分けがインターネット上で行われています。
「家族」「友人」「仕事」「飲み屋」など、グループ分けをしておくと名前で検索するよりも早く、またグループ分けのおかげで「○○さんは仕事関係の人だ」ってわかると思います。同じくドメインの情報もインターネット上ではグループ分けがされています。
したがって、Google Public DNSを用いてインターネット閲覧をする際には、Google Public DNSがこれら様々なグループから情報を持ってきてくるという仕事をしてくれます。ドメインのグループに関して、「.com」「.jp」「.org」「.co.jp」などドメイン名の違いやその詳細はJPNICよりご参照ください。図解付きでとても詳しい説明がされています。
[JPNIC]ドメイン名のしくみ:http://www.nic.ad.jp/ja/dom/system.html
さて、Google Public DNSを利用すると、以下JPNIC記載の画像を用いて説明すると
「自組織にあるネームサーバー」がGoogle Public DNSになります。
上記「自組織にあるネームサーバー」にGoogle Public DNSを用いると以下の理由で閲覧速度が向上します。
GoogleはGoogle検索サイトに情報を載せるため世界中のWebサイトにアクセスしそのコンテンツを確認しています。この時にGoogle検索サイトのクローラーが利用する多くのドメイン名の情報がキャッシュとして収められています。その為Google提供のDNSを「自組織内にあるネームサーバー」として設定することで、既にキャッシュとして存在するレコードを再利用するため、名前解決の時間を短縮できる。つまりは、Web閲覧の速度が向上します。
また、通常名前解決に使用するDNSサーバーは複数台で構成されており、見た目は1DNSサーバーでも負荷分散され実際は複数のDNSサーバーで情報を管理していることがあります。この場合、名前解決のキャッシュがそれぞれ個別のDNSサーバーに残ってしまい、既に名前解決はしているのに他のDNSサーバーで問い合わせを行なったため「キャッシュがない」となり、結果的に再度ルートDNSから問い合わせを行う必要が出てきますが、Google Public DNSはキャッシュを共有しているため、複数台のDNSの内1台が問いわせた内容を他のDNSサーバーに問い合わせしても「さっきDNSその1君が名前解決していたからそのキャッシュを使おう」という処理が行われるため、名前解決速度が向上しWeb閲覧速度向上につながります。
さらに、世界中のDNSに収められている情報はいつ変更されるかわからないため、ドメイン情報にはTTL(ティーティーエル:Time To Live)という使用期限が設定されており、このTTL値の間は一度問い合わせた情報をキャッシュして再利用し、TTL値を超えたら再度問い合わせを行うという仕組みがあるのですが、Google Public DNSはこのTTL値がすぎる前にDNS情報を定期的に再取得しに行きキャッシュするため「あ、TTL値が切れてるからまた問い合わせなきゃ」となることがありません。必然的にキャッシュが常に新しいモノになっているため、キャッシュがないために名前解決を再度する必要がなく、これもWeb閲覧向上に一役かってます。
最後に、GooglePublicDNSは、名前解決を行なっている接続元により近い場所に存在するDNSサーバーと通信をさせてくれるため、問い合わせしてから回答を得るまでの地理的距離を短縮でき、それにより名前解決の時間を短縮できます。
よしよし。
Google Public DNSでの名前解決が早いのは分かった。
公共で利用されるDNSなのに安全なの?
次のページにてセキュリティの向上がどのように図られているのかを説明します。
コメント
[…] 参考:Google Public DNS を使う理由を学びました。ちゃんちゃん。の巻 (TrippyBoyの愉快な日々) […]
こんばんは
オープンリゾルバの対策をしてくださいとレンタルサーバーから連絡がありました。
名前解決はバリュードメインのDNSサーバーを使ってるんでとめても問題ないと考えていたんですが、
wp-login.phpにホスト名でアクセス規制、/etc/hosts.allowでホスト名を規制してますけど、これが全部アクセスできなく
なってしまってえらいめにあいました。
俺自身sshでログインできず。webminのtextログインから復旧させる始末です・・・。
会社の環境は複数の回線と固定ipではないのでipのアクセス規制がむずかしいんですよね。
俺の部屋の回線は固定ipができるかどうか頼んでみるつもりです。
くりくりさん
こんばんは!今日はありがとうございました。
/etc/resolve.conf にてDNSの指定を解除したということですか!?(・・;)
うまく読み取れていなかったらすいませんっ
私はプロバイダのホスト名の末尾を用いて制限しています。
wp-login.phpはBasic認証で保護して、sahに関してはポートの変更とswatchで動的にブロックをかけて/etc/hosts.allowで数回弾かれたIPはiptablesでDROPしてます。
オープンリゾルバ対策する場合はnamed.confで再帰的問い合わせを禁止しました。
recursion no;
allow-query-cache { localhost; };
この設定をいじっていたらアクセスできない事象が発生しました。
それはそれでいいんですが、
最近はネット経由でコンソール接続ができるのでそれを試してみたら出来ない!!
今日一日メールでレンタルサーバーとやりとりです。
bindは昔から苦手で困ったものです。
くりくりさん
ご自身のサーバー上にDNSを構築されて、かつサーバー自身の名前解決を構築されたDNSで行われている状況でrecursion no;にされたということでしょうか。これは外部サーバーに名前解決を行いに行かない設定と思われます。。問題になっちゃいますね(^^;;
forwarderとしてGooglePublicDNSを指定されてみてはいかがでしょうか。
サーバー自身の名前解決を自身のDNSにしないか
DNSへ問い合わせる接続元を制限するか
forwarderの設定をするかで対応できるかと思います!
recursion no;危険ですよねw
yesにして結局,iptablesでポート53をとじました。
思い出したのが
私の前の管理者がやはりnoにしていてyum updateがエラーはいてしまい。
yesに変更したんですよ。
>サーバー自身の名前解決を自身のDNSにしないか
>DNSへ問い合わせる接続元を制限するか
>forwarderの設定をするかで対応できるかと思います!
うちのサーバーで試してみて会社にあてることにします・・・。
bindの設定でallow-queryなどを使った制限もしておいた方がいいかもしれませんね(^_^)☆
iptablesで53番を制限したなら問題なさそうです!
[…] Google Public DNS を使う理由を学びました。ちゃんちゃん。の巻 […]