という記事がありました。
いまはGoogl Publoc DNSを使用中。問い合わせ先を変えたらホントに早くなるんかいのー?
ということで、計ってみた
WindowsではDigが使えないので、みんなの味方CMANさんのDNSチェックを利用。 FQDN:piroshi07.comでdig実行し、表示結果の「Query time: xxx msec」の値を記録。 3回実行を繰り返した結果が以下。
プロバイダ | IPアドレス | 測定(1回目) | 測定(2回目) | 測定(3回目) |
Cloudflare | 1.1.1.1 | 132 msec | 2 msec | 1 msec |
8.8.8.8 | 124 msec | 126 msec | 276 msec | |
Quad9 | 9.9.9.9 | 347 msec | 344 msec | 114 msec |
OpenDNS | 208.67.222.222 | 399 msec | 279 msec | 357 msec |
Cloudflareの2回目以降の結果がおかしい。1桁ってどういうこと?キャッシュ?? 考えられることとして…
- 同一IPアドレス(ロードバランサ)の後ろに複数台のDNSサーバがぶら下がっているはずで、毎回同一のDNSリゾルバが応答してくれているわけではないはず。なのでキャッシュを持ったDNSサーバに当たるかは運次第。
- Cloudflareは、DNSリゾルバ全体でキャッシュ情報を共有する仕組みがある?か、同一の問い合わせ元には同一のDNSリゾルバを割り当てるような負荷分散処理になっている。
- もしくは利用者が超絶少なくてキャッシュが残る可能性が高い?(他は問い合わせ数多くてすぐ消えちゃう)
ちなみに、一時間後にDigってみてもQuery time: 2msecという結果だった。
ping応答も計ってみた
ただ、Query time(=DNS問い合わせにかかった時間)が短いからってクライアントまでの応答が早いってわけじゃないよね。
手元のPCからのping応答を確認。 ※UQ mobileのWiMAXでインターネットに接続。接続元情報を確認くんで調べた結果↓
↓Ping結果
#Cloudflare 1.1.1.1 に ping を送信しています 32 バイトのデータ: 1.1.1.1 からの応答: バイト数 =32 時間 =305ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =122ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =142ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =88ms TTL=53 1.1.1.1 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 88ms、最大 = 305ms、平均 = 164ms #Google 8.8.8.8 に ping を送信しています 32 バイトのデータ: 8.8.8.8 からの応答: バイト数 =32 時間 =82ms TTL=117 8.8.8.8 からの応答: バイト数 =32 時間 =68ms TTL=117 8.8.8.8 からの応答: バイト数 =32 時間 =81ms TTL=117 8.8.8.8 からの応答: バイト数 =32 時間 =82ms TTL=117 8.8.8.8 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 68ms、最大 = 82ms、平均 = 78ms #Quad9 9.9.9.9 に ping を送信しています 32 バイトのデータ: 9.9.9.9 からの応答: バイト数 =32 時間 =220ms TTL=51 9.9.9.9 からの応答: バイト数 =32 時間 =192ms TTL=51 9.9.9.9 からの応答: バイト数 =32 時間 =424ms TTL=51 9.9.9.9 からの応答: バイト数 =32 時間 =185ms TTL=51 9.9.9.9 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 185ms、最大 = 424ms、平均 = 255ms #OpenDNS 208.67.222.222 に ping を送信しています 32 バイトのデータ: 208.67.222.222 からの応答: バイト数 =32 時間 =262ms TTL=47 208.67.222.222 からの応答: バイト数 =32 時間 =156ms TTL=47 208.67.222.222 からの応答: バイト数 =32 時間 =178ms TTL=47 208.67.222.222 からの応答: バイト数 =32 時間 =307ms TTL=47 208.67.222.222 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 156ms、最大 = 307ms、平均 = 225ms
絶対王者Google。到達ホップ数が少ないせいか、応答時間の揺らぎも小さい。anycastが効いていて、ピアリングで優位?
ついでにtracertもうってみた。
#Google google-public-dns-a.google.com [8.8.8.8] へのルートをトレースしています 経由するホップ数は最大 30 です: 1 2 ms 2 ms 3 ms speedwifi-next.home [192.168.100.1] 2 * * * 要求がタイムアウトしました。 3 93 ms 73 ms 77 ms 172.25.157.162 4 227 ms 67 ms 57 ms 172.25.157.38 5 159 ms 77 ms 69 ms 172.25.157.125 6 255 ms 78 ms 85 ms 172.25.157.177 7 78 ms 54 ms 59 ms tmfISN004.bb.kddi.ne.jp [27.85.209.53] 8 86 ms 71 ms 64 ms 27.85.199.41 9 104 ms 74 ms 84 ms 27.80.241.161 10 79 ms 81 ms 77 ms 27.85.134.14 11 96 ms 73 ms 68 ms 74.125.51.213 12 * * * 要求がタイムアウトしました。 13 * 175 ms 98 ms 74.125.251.234 14 * * 212 ms 108.170.238.81 15 * 157 ms 79 ms google-public-dns-a.google.com [8.8.8.8] トレースを完了しました。 #Cloudflare one.one.one.one [1.1.1.1] へのルートをトレースしています 経由するホップ数は最大 30 です: 1 5 ms 1 ms 2 ms speedwifi-next.home [192.168.100.1] 2 * * * 要求がタイムアウトしました。 3 268 ms 74 ms 75 ms 172.25.157.162 4 141 ms 78 ms 88 ms 172.25.157.38 5 113 ms 74 ms 75 ms 172.25.157.125 6 89 ms 68 ms 56 ms 172.25.157.177 7 164 ms 82 ms 78 ms tmfISN004.bb.kddi.ne.jp [27.85.209.53] 8 88 ms 69 ms 87 ms 27.85.199.33 9 94 ms 66 ms 62 ms 27.80.241.161 10 183 ms 66 ms 57 ms 27.85.134.14 11 85 ms 70 ms 89 ms as13335.ix.jpix.ad.jp [210.171.224.134] 12 75 ms 80 ms 73 ms one.one.one.one [1.1.1.1]
あれ、Cloudflareのホップ数とping時のTTL値の計算あわなくね?? TTL=20に指定して再度ping。
ping 1.1.1.1 -i 20 1.1.1.1 に ping を送信しています 32 バイトのデータ: 1.1.1.1 からの応答: バイト数 =32 時間 =103ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =104ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =85ms TTL=53 1.1.1.1 からの応答: バイト数 =32 時間 =90ms TTL=53
…Cloudflare側でTTL値を書き換えてたりするのかな?
あ、そういえばWiMAX、3日間で7GB超えちゃって帯域制限入ってるし、応答速度もあんまりアテにならないな。
結論
判断保留。 これまで通り、Google Public DNSを使います。