digはDNSサーバーから正しい結果を取得しますが、名前はまだ解決できません

digはDNSサーバーから正しい結果を取得しますが、名前はまだ解決できません

どのような条件下で次のようなことが起こるでしょうか? 内部ネットワーク上の特定の OSX マシンからの場合:

$~ cat /etc/resolv.conf
nameserver 10.102.120.7
nameserver 10.102.120.2

同じマシンから:

$~ dig @10.102.120.7 in.local
<snip> ...
;; QUESTION SECTION:
;in.local.                      IN      A

;; ANSWER SECTION:
in.local.               43200   IN      A       10.102.123.30
<snip> ...

それでも、このワークステーションは in.local に ping できず、そのマシン上の apache によってホストされているページもロードできません。10.102.123.30 は確実に稼働しています (私が知っている 2 台の OSX マシンは in.local を解決できませんが、ネットワーク上の他のマシンは解決できます)。また、干渉する可能性のあるものがないか /etc/hosts も確認しました... 他に何を確認すればよいかわかりません...

答え1

tld.localは、最初に MacOS X 上でマルチキャスト DNS Bonjour/Rendezvous によって解決されます。つまり、tld で DNS サーバーを使用しようとすると.local、DNS サーバーを使用して解決されません。

一部のプライベート ネットワークでは、パブリック インターネット上の有効なトップレベル ドメインではないにもかかわらず、内部 DNS サーバーに登録されたホストに「.local」ドメインを使用します。Mac がこのようなネットワークに接続されている場合は、インターネット上で「www.apple.com」などのホスト名を検索するのと同じように、ユニキャスト DNS を使用して DNS サーバーと通信し、「.local」で終わるホスト名を検索するようにするとよい場合があります。

見る:http://support.apple.com/kb/HT3473 そして:http://support.apple.com/kb/TA20999

答え2

OS X には OS レベルの DNS キャッシュがあり、solaris/linux/bsd の nscd のようにフラッシュする必要がある場合があります。

dscacheutil -flushcache(Leopard の場合) またはlookupd -flushcache(10.5.1 以前) を 試してください。

答え3

その理由が分かった.LOCAL を使うのは良くない考えです

答え4

考えられる唯一のことは、名前サービスに DNS を使用していないか、名前がキャッシュされていることです。

私は Linux に詳しいのですが、OSX の /etc/ に相当する nsswitch.conf (または同等の) ファイル、またはキャッシュ デーモン (Linux では nscd) の構成 (nscd.conf) または状態を探している可能性があります。

nsswitch.conf は、名前の解決方法を制御します。DNS は 1 つのメカニズムにすぎません。他のメカニズムとしては、ファイル (/etc/host)、LDAP、および (おそらく) NIS などがあります。

nscd は、同じ名前のリクエストが繰り返し発生する場合 (たとえば、Web サーバーから 300 ページをロードする場合) に、応答を適切な時間 (たとえば、dig の出力例から 43200 秒) キャッシュすることで、名前の解決を高速化するのに役立つ名前キャッシュです。

関連情報