10月 19

iPod touchの名前解決の仕組み

Inside of iPod touch No Comments »

※このエントリは書きかけです。まだ詳細は不明です。詳細がわかったら追記予定です。

iPod touchを複数の無線LANに接続して利用することは多いと思います。環境によってインターネットへの接続ができるところとできないところがあります。ここまでは当り前の話なのですが、以下の状況の挙動がちょっとおかしいようです。(Version 2.1)

  • インターネットへのTCP/IPレベルでの通信は可能
  • DHCPで配布されるDNSサーバーでのインターネット上のホストの名前解決は不可能
  • 別途指定したDNSサーバーでのインターネット上のホストの名前解決は可能

わざわざWi-Fi接続後に「設定」→「Wi-Fi」→接続されているワイヤレスネットワーク→「DNS」にてDNSサーバーを指定しているわけですが、この状態で名前解決ができず、「インターネットに接続していない」として怒られてしまうことが多いのです。でも、設定を何も変更しなくても接続可能な時もあります。

予想としては、インターネット上のホストの名前解決ができないDNSを参照しているときに、通信が発生してしまう。その時に「名前解決できない」というネガティブキャッシュが生成され、それが長時間保持されてしまっているのではないかと考えています。

iPod touchの名前解決の仕組みを調べてみようと考え中です。

 

(2008/10/14 追記)

まずはipod touchの名前解決の仕組みに関してWeb上で情報がないか探してみました。…が、あまりそれらしい情報が見つけられません。見つかったのは以下のもの程度。

  • 【iPod touch -Tips & Hacks – ver.4】

      /usr/lib/libc.dylibのgethostbyname()がおかしいようです。
      別途用意した同名関数を持つlibresolv.aを使ってコンパイルすると、
      ホスト名がrecordの場合は名前解決に成功、cnameの場合は失敗といった感じとのこと。
      Cocoaアプリは、CoreFoundationの何かのクラスのメソッドを使っているんでしょうね。
      ちなみに、DNS Toolsをインストールすると、それだけで名前解決できるようになる場合があります。
      （libbindがインストールされるから?）
      curl, wgetなどで確認。ただ、この場合も環境が変わるとダメになることが。
      自分の経験では家ではOK、会社ではダメ。
      その場合でも、DNS Toolsに含まれるhostコマンドなんかでは名前解決できてます。
      libbindにもgethostbyname()があるから、これを使うようリンクされているのかもしれないです。

単純にバグがあるのでしょうか?でも、この情報は2007年11月の情報なので、直っているかもしれませんが…。ちょっとこの方向での情報収集は難しそうです。

仕方がないので、自分なりに調べてみます。

まず、プロセスを調べてみました。

iPod:/var/run root# ps -ax
  PID TTY           TIME CMD
    1 ??         0:06.40 /sbin/launchd
   13 ??         0:00.68 /Applications/MxTube.app/MxT2d
   15 ??         0:04.94 /usr/sbin/update
   16 ??         0:33.16 /usr/sbin/syslogd
   17 ??         0:10.97 /usr/libexec/lockdownd
   18 ??         6:32.02 /usr/sbin/mediaserverd
   19 ??         0:09.32 /usr/sbin/mDNSResponder -launchd
   21 ??         0:08.96 /System/Library/PrivateFrameworks/IAP.framework/Suppor
   22 ??         0:00.81 /usr/sbin/fairplayd
   24 ??         2:04.65 /usr/sbin/configd
   25 ??         7:18.32 /System/Library/CoreServices/SpringBoard.app/SpringBoa
   28 ??         0:02.55 /System/Library/PrivateFrameworks/CoreTelephony.framew
   30 ??         0:12.13 /usr/sbin/notifyd
   46 ??         1:13.94 /var/stash/Applications.Y8SKDX/MobileMail.app/MobileMa
   66 ??         0:32.38 /System/Library/Frameworks/SystemConfiguration.framewo
  184 ??         0:59.81 /System/Library/PrivateFrameworks/DataAccess.framework
  245 ??         0:38.78 /var/stash/Applications.Y8SKDX/MobileMusicPlayer.app/M
  308 ??         0:03.33 /usr/sbin/sshd -i
  316 ??         0:33.22 /var/mobile/Applications/64786510-4BDD-4BD6-A43A-32C1F
  331 ??         0:00.45 /System/Library/SystemConfiguration/EAPOLController.bu
  335 ??         0:00.14 /usr/libexec/amfid
  309 ttys000    0:00.68 -sh
  337 ttys000    0:00.02 ps -ax

/usr/sbin/mDNSResponderというプロセスがそれっぽいです。これを調べてみました。

これをキーに検索してみると結構情報が出てきます。

  • 【コラム】OS X ハッキング! (57) OS X独自のコマンドたち(1) | パソコン | マイコミジャーナル

      Jaguarにおける新機能の1つ「Rendezvous」は、マルチキャストDNSという機構を利用して名前解決を行う。Rendezvousに対応するすべてのノードは自分のホスト名(FQDN名)を認識し、他のノードからの自分の名前に対するリクエストに応答することでIPアドレスとホスト名の相互変換を実現する。この機能のスイッチはシステム環境設定に用意されていないため、シングルユーザモード時以外は常に有効な状態になっている。

      Rendezvousの実体は、そのマルチキャストDNSの機能を提供する「mDNSResponder(/usr/sbin /mDNSResponder)」というOS X独自のコマンドだ。シェルから「mDNSResponder」を通常のコマンドとして実行しても反応はないが、以下のようにSystemStarter コマンドを使えばRendezvousを無効化できる。

でも、この「マルチキャストDNS」という機構やmDNSResponderという名前からすると自らの名前解決の機構というわけではなく、DNS(マルチキャストDNS)の問い合わせに対して応答する側のサービスのようです。今回と完全にかはわかりませんが、無関係ですねきっと…。と、思って探したら以下のページがありました。

  • Mac OS X Hacking Tools
      mDNSResponder

      /usr/sbin/mDNSResponder (Multicast DNS Responder) listens for and responds to DNS-format query packets sent via Multicast to UDP port 5353.

うーん残念。これはやっぱり無関係っぽい。ということで、また時間ができたら継続的に調べます。

 

(2008/10/15追記)

時間がなくてあまり調査は進んでいないけれども、2つわかったことがあるのでメモ。

  • 別の場所から移動してきた後でWi-Fiの範囲に入り、DHCPからIPを取得してDNSの値が正しい状態になっているまま一定の場所に長時間(8時間程度)置いておいても、iPod touchをスリープさせたままにしておくと名前解決ができる状態にはならない→刺激がないと名前解決周りの状態が変化しないのではないか
  • 上記の状態(名前解決ができない状態)を確認した直後にrebootしてやり、起動直後にインターネットにアクセスさせると名前解決に成功する。→起動直後にDHCPから取得した情報は正常に使える

このことから、「名前解決ができるはずなのにできない」という状況は「直前のDNS参照先の設定が残ってしまっていて、最新のDNS参照先に問い合わせに行かない状態」なのではないかと予想します。

さて、正しい予想かどうか…。