iPhoneの無線LAN(Wi-Fi)通信の速度を速くするために、何かしらできることはないかと思っていたが、Google Public DNSを設定すればホスト名解決時のDNS Queryがほんの少しスピードアップするのでは?と思った。ただ、闇雲にGoogle Public DNSにしても速いかどうかわからないので、PCでいくつかのDNSサーバーの応答速度を測定してみることにした。

現在のiPhone5の設定を確認

iPhoneのWi-FiはDHCPでアドレス割り当てを行なっていて、これは、NTTフレッツ光のルーターがDHCPサーバーになっている。このとき、どのようにDNSサーバーのIPが割り当てられているか確認してみた。
「設定」

「Wi-Fi」画面で、 自分の利用しているWi-Fiアクセスポイントを選択する。
iPhone Wi-Fi Settings


iPhone_cuurent

すると、ウチの環境では、192.168.5.1と、NTTフレッツ光のルーターが設定されている。
※「2408:80:bd6:・・・」というIPv6アドレスはおそらくフレッツ網のDNS?

DNSサーバーの応答速度を測定

Google Public DNS(8.8.8.8、8.8.4.4) と、NTTフレッツ光のルーター(192.168.5.1)、プロバイダの提供DNSをDomain Name Speed Benchmarkで比較してみた。
※ NTTフレッツ光のルーター(192.168.5.1)には、DNSに8.8.8.8を指定している。
測定した結果は次のようになった。(Uncached Nameの主なものを抜粋)
DNS Benchmark result

No. DNS Uncached Name Average(s)
1 NTT America Technical Operations 0.082
2 プロバイダ提供DNS 0.092
3 Google Public DNS(8.8.8.8、8.8.4.4) 0.130
4 NTTフレッツ光のルーター(192.168.5.1) 0.140

NTT America Technical Operationsが速いがこれは、Publicなものかどうか不明なのでSKIP。
NTTフレッツ光のルーターやGoogle Public DNSより、プロバイダ提供するDNSの方が40~50msくらい速い。
キャッシュされていないホストのコンテンツを見る場合は微妙に速いようだ。
キャッシュされている場合も、若干の差だが、プロバイダ提供DNSが5msほど速い。
※ あくまでもウチでの計測結果です。利用回線や地域、プロバイダ等によって結果は異なります。

iPhoneのWi-FiのDNSをプロバイダが提供するDNSに設定

「設定」→「Wi-Fi」→「アクセスポイント」画面でDHCPで割り振られたDNSのアドレスを消し、プロバイダ提供DNSのアドレスを入力した。(DNS2つの場合は「,」で区切って2つ記載する。)
iPhone Wi-Fi DNS Settings

結果、ブラウザの表示速度が少し速くなったような気がする。気のせいに近い?5~50msくらいは速いはずだが...

その他

それと、ついでに見つけた情報、Google Public DNS FAQによると、akamaiなどのCDN(コンテンツを高速に配信するための分散配信のしくみ)とGoogle Public DNSは相性が悪く、ネットワーク的に「遠い」CDN配布ポイントを返すことがあるらしい。しかも、Akamai Technologiesによると、Apple、iTunes Store、Microsoftとか、akamaiを使ってるかもしれない。
そういえば、少し前に画像等ををakamaiに置いている銀行系のサイトで、CDNなのに随分遅いと思ったことがあった。
闇雲にGoogle Public DNSを設定するとまずいようだ。
ルータのDNSの代行機能やプロバイダ提供DNSがとても遅い・キャッシュヒット率が低いとかの場合にGoogle Public DNSを設定したほうが結果的には良さそうだ。これからはDNSの測定をやってどのDNSサーバーを使うかは総合的に判断しよう。

Google Public DNS FAQ
I've read claims that Google Public DNS can slow down multimedia applications such as iTunes and Apple TV. Are these true?
Many sites that provide downloadable or streaming multimedia host their content with DNS-based third-party content distribution networks (CDNs), such as Akamai. When a DNS resolver queries an authoritative nameserver for a CDN's IP address, the nameserver returns an address which is closest (in network distance) to the resolver, not the user. In some cases, for ISP-based resolvers as well as public resolvers such as Google Public DNS, the resolver may not be in close proximity to the users. In such cases, the browsing experience could be slowed down somewhat. Google Public DNS is no different from other DNS providers in this respect.
To help reduce the distance between DNS servers and users, Google Public DNS has deployed its servers all over the world. In particular, users in Europe should be directed to CDN content servers in Europe, users in Asia should be directed to CDN servers in Asia, and users in the eastern, central and western U.S. should be directed to CDN servers in those respective regions. We have also published this information (see Where are your servers currently located? for details) to help CDNs provide good DNS results for multimedia users.
In addition, Google Public DNS engineers have proposed a technical solution to the issue in an IETF draft, Client subnet information in DNS requests. This proposal defines an EDNS0 extension which allows resolvers to pass in part of the client's IP address as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver. We have deployed an implementation of the proposal as an experiment for content distribution networks and Google properties. We look forward to working with other public resolvers and other content networks as part of the Global Internet Speedup to conduct further experiments.
Finally, if you are having a specific problem, please see the troubleshooting page or send a message to the public forum.

しかし、EDNS0 extensionなんてすぐに普及しなさそうだが。。