アカウント名:
パスワード:
問題は、そのDNSサーバが「DNSリクエストを処理するのにどれくらい時間がかかるか」でしょう。
ISPのDNSサーバなんかは、問い合わせが来てから、リクエストされたホストを管理してるDNSサーバに再問い合わせをし、得られた返事をしますから、それなりに時間がかかります。一方、Google の DNS サーバは、キャッシュすることで、再問い合わせ無しに返答できる可能性が高く、その場合は非常に高速に結果が得られます。
ISPのDNSサーバまでがping 10ms、 Googleのが50msとして「通信遅延が5倍遅い」としても、問い合わせられたリクエストを処理するのに、ISPのDNSサーバが100ms、Google のが1msで返すなら、DNSによる名前解決の所要時間は、110ms対51msで、Googleのを使う方が2倍速いことになります。
今、試してみたら、こんな感じになりました。
・ローカルで立ててるDNSサーバ% ping @192.168.x.x64 bytes from 192.168.x.x: icmp_seq=0 ttl=128 time=0.157 ms% dig www.freebsd.org @192.168.x.x1回目: ;; Query time: 129 msec2回目: ;; Query time: 1 msec
・プロバイダのDNSサーバ% ping x.x.x.x64 bytes from x.x.x.x: icmp_seq=0 ttl=54 time=15.507 ms% dig www.freebsd.org @x.x.x.x1回目;; Query time: 174 msec2回目;; Query time: 17 msec
・GoogleのDNSサーバ% ping 8.8.8.864 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=47.578 ms% dig www.freebsd.org @8.8.8.81回目: ;; Query time: 47 msec2回目: ;; Query time: 48 msec
まあ、普通のDNSサーバもキャッシュはしてますから、Googleが早いのは1回目だけですが、それでも「ネットサーフィンで、新たなページをブラウズしようとしたとき」の応答時間なんかは、それなりに改善されるんじゃないかと思います。
と、ここまで書いたところで「ローカルでDNSサーバを立てた上で、8.8.8.8 に forward する」のが最強な気がしました。…早速実験。FreeBSD-7.2-RELEASE/bind 9.6 で、named.conf の options に forwarders { 8.8.8.8; }; を追加。
% dig www.freebsd.org @192.168.x.x1回目: ;; Query time: 49 msec2回目: ;; Query time: 1 msec
うむ。なかなか良さそう。
> と、ここまで書いたところで「ローカルでDNSサーバを立てた上で、8.8.8.8 に forward する」のが最強な気がしました。うちのLinuxもそうしよう。# というか外向きをずっとメンテしてないや…orz
WindowsだとDNS Client(Dnscache)サービスがいるので、DNSとして8.8.8.8を設定したとしても自動的にローカルキャッシュが効きます。
むしろ、ISPがこのGoogle Public DNSをつかう、、、「53は全部8.8.8.8にforwardしておけば」みたいな感じで（w送信元（顧客からすればDNSサーバのIP）をISPのIPでNATしておけば、Googleに顧客情報が漏れる事も無いし、そもそも、まず客に気づかない。
これは美味しい、、のか？サーバ１、２台の管理コストが浮く程度だけど。
ちょっと困ったときはping 8.8.8.8nslookup hoge 8.8.8.8を使おうかしらん
DNSの応答性能をあげたいならばローカルでキャッシュサーバ立ててキャッシュしねぇ？だから遅延って応答性能に関してはかなり問題だと思うんだけどな。世界各地で立ち上げるのかもね？
Google の目的が快適な Web Browse である以上、標準の DNS が遅いときは Chrome がこいつを参照してキャッシュするということでは？
Tracerouteを見ると突然30msec増えるので、ここで東京から光ファイバーで海を越えたとすると東京から3000kmのあたりにあるサーバにつながっている可能性高いです。
香港あたりのDCかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ISPより遠いけど (スコア:0)
Reply from ***.***.184.90: bytes=32 time=11ms TTL=58
Reply from ***.***.184.90: bytes=32 time=16ms TTL=58
Reply from ***.***.184.90: bytes=32 time=10ms TTL=58
Reply from ***.***.184.90: bytes=32 time=11ms TTL=58
GoogleのDNSサーバ
Reply from 8.8.8.8: bytes=32 time=50ms TTL=241
Reply from 8.8.8.8: bytes=32 time=51ms TTL=241
Reply from 8.8.8.8: bytes=32 time=51ms TTL=241
Reply from 8.8.8.8: bytes=32 time=48ms TTL=241
少々遠いが日本からの使用でも応答がよくなるのだろうか
Re:ISPより遠いけど (スコア:5, 参考になる)
問題は、そのDNSサーバが「DNSリクエストを処理するのにどれくらい時間がかかるか」でしょう。
ISPのDNSサーバなんかは、問い合わせが来てから、リクエストされたホストを管理してるDNSサーバに再問い合わせをし、得られた返事をしますから、それなりに時間がかかります。
一方、Google の DNS サーバは、キャッシュすることで、再問い合わせ無しに返答できる可能性が高く、その場合は非常に高速に結果が得られます。
ISPのDNSサーバまでがping 10ms、 Googleのが50msとして「通信遅延が5倍遅い」としても、
問い合わせられたリクエストを処理するのに、ISPのDNSサーバが100ms、Google のが1msで返すなら、
DNSによる名前解決の所要時間は、110ms対51msで、Googleのを使う方が2倍速いことになります。
今、試してみたら、こんな感じになりました。
・ローカルで立ててるDNSサーバ
% ping @192.168.x.x
64 bytes from 192.168.x.x: icmp_seq=0 ttl=128 time=0.157 ms
% dig www.freebsd.org @192.168.x.x
1回目: ;; Query time: 129 msec
2回目: ;; Query time: 1 msec
・プロバイダのDNSサーバ
% ping x.x.x.x
64 bytes from x.x.x.x: icmp_seq=0 ttl=54 time=15.507 ms
% dig www.freebsd.org @x.x.x.x
1回目;; Query time: 174 msec
2回目;; Query time: 17 msec
・GoogleのDNSサーバ
% ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=47.578 ms
% dig www.freebsd.org @8.8.8.8
1回目: ;; Query time: 47 msec
2回目: ;; Query time: 48 msec
まあ、普通のDNSサーバもキャッシュはしてますから、Googleが早いのは1回目だけですが、
それでも「ネットサーフィンで、新たなページをブラウズしようとしたとき」の応答時間なんかは、
それなりに改善されるんじゃないかと思います。
と、ここまで書いたところで「ローカルでDNSサーバを立てた上で、8.8.8.8 に forward する」のが最強な気がしました。
…早速実験。FreeBSD-7.2-RELEASE/bind 9.6 で、named.conf の options に forwarders { 8.8.8.8; }; を追加。
% dig www.freebsd.org @192.168.x.x
1回目: ;; Query time: 49 msec
2回目: ;; Query time: 1 msec
うむ。なかなか良さそう。
Re:ISPより遠いけど (スコア:2, 参考になる)
> と、ここまで書いたところで「ローカルでDNSサーバを立てた上で、8.8.8.8 に forward する」のが最強な気がしました。
うちのLinuxもそうしよう。
# というか外向きをずっとメンテしてないや…orz
WindowsだとDNS Client(Dnscache)サービスがいるので、DNSとして8.8.8.8を設定したとしても自動的にローカルキャッシュが効きます。
Re: (スコア:0)
Re:ISPより遠いけど (スコア:1, おもしろおかしい)
> % ping @192.168.x.x
何を隠したかったんでしたっけ・・・・
予想してみる (スコア:2, おもしろおかしい)
>何を隠したかったんでしたっけ・・・・
x.xの部分が
1. ちょっと恥ずかしい語呂合わせ系になっている
（例）69.69 、46.49、59.63
2. 車のナンバーや誕生日など、個人情報成分が混入している
#べ、別にうちのサーバーのことじゃないからねっ
#勘違いしないでよねっ
Re: (スコア:0)
なかーまいたいた。 自分もそうしますね。 そろそろISPがいらない時代かなと思いました。
回線屋がDHCPまいてくれてGoogle DNSがあれば、そこはもうインターネッツてか。
Re: (スコア:0)
むしろ、ISPがこのGoogle Public DNSをつかう、、、
「53は全部8.8.8.8にforwardしておけば」みたいな感じで（w
送信元（顧客からすればDNSサーバのIP）をISPのIPでNATしておけば、
Googleに顧客情報が漏れる事も無いし、そもそも、まず客に気づかない。
これは美味しい、、のか？サーバ１、２台の管理コストが浮く程度だけど。
Re:ISPより遠いけど (スコア:1)
ちょっと困ったときは
ping 8.8.8.8
nslookup hoge 8.8.8.8
を使おうかしらん
Re: (スコア:0)
DNSの応答性能をあげたいならばローカルでキャッシュサーバ立ててキャッシュしねぇ？
だから遅延って応答性能に関してはかなり問題だと思うんだけどな。
世界各地で立ち上げるのかもね？
Re:ISPより遠いけど (スコア:1)
Google の目的が快適な Web Browse である以上、標準の DNS が遅いときは Chrome がこいつを参照してキャッシュするということでは？
Re: (スコア:0)
Tracerouteを見ると突然30msec増えるので、ここで東京から光ファイバーで海を越えたとすると東京から3000kmのあたりにあるサーバにつながっている可能性高いです。
香港あたりのDCかな。