FQDNまたはマシン名をローカルネットワーク(mycompany.internal)のIPアドレスに解決する場合、コマンドライン(linux/mac)またはnslookup(windows)でDigを使用して、構成されたサーバーにクエリを実行し、応答を取得できます。ただし、pingコマンドまたはWebブラウザにFQDNまたはマシン名だけを入力しようとすると、「不明なホスト」またはDNSエラーが発生します。これがサンプルです。これはMacからのものです。
mac:~ atroon$ Dig server.mycompany.internal
; <<>> Dig 9.6.0-Apple-P2 <<>>
server.mycompany.internal ;; global
options: +cmd ;; Got answer: ;;
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5219 ;; flags: qr aa rd
ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 0
;; QUESTION SECTION:
;server.mycompany.internal. IN A
;; ANSWER SECTION:
server.mycompany.internal. 1200 IN A 172.16.254.36
;; Query time: 0 msec ;; SERVER:
172.16.254.8#53(172.16.254.8) ;; WHEN: Wed Dec 16 11:39:15 2009 ;; MSG SIZE
rcvd: 55
mac:~ atroon$ ping server.mycompany.internal<br>
ping: cannot resolve server.mycompany.internal: Unknown Host
私は私の人生のためにこれを理解することはできません。 DNSサーバーはSBS2003ボックスであり、小規模企業ネットワークのAD、一部のファイル/印刷などを処理します。この問題は週に約3回発生し、ローカルネットワークに直接接続している場合は、サーバーと同じスイッチでも発生します。 IPアドレスを使用して任意の接続を確立できますが、DNSを機能させることはできません。さらに、私はこれを経験していると同時に、他のユーザーは大丈夫です。それは私のMacの問題だと思います。しかし、どのような問題がありますか? Digはどのようにしてクエリを送信して応答を取得し、「不明なホスト」とpingを送信できますか?
これはサーバーの問題ではなくローカルの問題だと思うので、ここにvs. serverfaultを投稿します...しかし、誰かが私をサーバーに向けることができれば、私たちは1つか2つのドメインに向かうと思います。
使用しているMacOS Xのバージョンに応じて、システムによるDNSの処理方法が変更されました。
基本的に、Mac OS Xには2つのDNS解決メカニズムがあります。標準のUNIXアプローチ(/etc/resolv.conf
)これはDig
によって使用され、次にシステムの他の部分によって使用されるアプローチです。
Mac OS X 10.4および10.5では、2つのアプローチははるかに緊密に結びついていました。片方をリフレッシュすると、両方をリフレッシュする傾向がありました。ただし、10.6およびそれよりはるかに少ない程度の10.5では、システム解決メカニズムの値がまだ悪い場合でも、Dig
で正しい値を指定することができます。
Mac OS Xの各バージョンのDNSキャッシュをフラッシュするには:
lookupd -flushcache
dscacheutil -flushcache
Sudo dscacheutil -flushcache
またはSudo killall -HUP mDNSResponder
(最初のコマンドは2番目のコマンドを実行するはずですが、10.6の以前のバージョンでは表示されませんでした)ping
思い出すと、システムルックアップを使用しているため、解決メカニズムが異なります。 /etc/resolv.conf
は常にDNSサーバーを順番に使用しますが、mDNSResponder
は、セットアップによっては後部を噛む可能性のある「スマート」にしようとします。
また、MacやDHCP経由で複数のDNSサーバーを指定していますか? Snow Leopardは、DNSサーバーの順序が変わる別の動作(バグ?)を導入しました。これは、分割DNS(内部では1つのIPを使用しますが、外部では別のIPを使用します)で大混乱を引き起こします。これは、2番目のサーバー(今回は外部)に順番に要求する前に、最初に内部DNSサーバーに要求を停止する場合があるためです。これはおそらく、DNS関連の遅延を回避するために最速のDNSサーバーに接続する方法です。 10.6.3より前の最も簡単な修正は、DHCP経由でのみ内部DNSサーバーにサービスを提供し、DNSサーバーの転送設定がそれに応じて設定されていることを確認することです。
10.6.3以降、mDNSResponderに、DNS要求時間を最適化しようとせず、常に適切な順序を使用するように指示することができます。これを行うには、キーStrictUnicastOrdering
を追加し、それをmDNSResponderのLaunch Daemon plistにtrueに設定します(必要に応じてリロードします)。
Mac OS X v10.6では、デフォルトのDNSサーバー検索動作では、サーバーが結果を返さず(クエリに対してSERV_FAILを返す)、他のサーバーがクエリに使用できる場合、サーバーは次の検索順序で一時的に無効になります。約30秒。クエリに複数のサーバーがあり、それらすべてがSERV_FAILを返した場合、サーバーは無効にされた順序でクエリされます(つまり、最も長く無効にされたサーバーが最初に使用されます)。
(出典: support.Apple.com そして私がやる前にこれを上げてくれたYarに感謝します。)
次のコマンドを実行することで、これを自動化できます(Appleのコマンドよりも少し速く簡単です)。
Sudo /usr/libexec/PlistBuddy -c "Add :StrictUnicastOrdering bool true" /System/Library/LaunchDaemons/com.Apple.mDNSResponder.plist
そして実行することによってそれを逆にします:
Sudo /usr/libexec/PlistBuddy -c "Delete :StrictUnicastOrdering" com.Apple.mDNSResponder.plist
または、次を実行してmDNSResponderを再起動するには、launchdでジョブをリロードする必要があります。
Sudo launchctl unload /System/Library/LaunchDaemons/com.Apple.mDNSResponder.plist
その後Sudo launchctl load /System/Library/LaunchDaemons/com.Apple.mDNSResponder.plist
最後に、10.6.3と 少しいじる のおかげで修正されました。基本的には、com.Apple.mDNSResponder.plist
を変更してから、dnsresponderを再起動します。
私は間違っているかもしれませんが、指示は間違っていると思います。最初にSudo cp
と書かれているところにSudo mv
と言うべきです。
/etc/resolv.conf
の内容を調べて、Macが使用しているネームサーバーを確認します。ネットワーク設定でネームサーバーを追加することもできます。使用しているアダプタを選択し、[詳細...]ボタンをクリックしてから、[DNS]タブをクリックします。
Macの場合、DNSキャッシュをフラッシュするコマンドラインツールは次のとおりです。
dscacheutil -flushcache
更新:
discussions.Apple.comのこのスレッド でたくさんの良いものを見つけました。例えば:
Dig(1)(およびHost(1)とnslookup(1))はすべて、DNSリゾルバーを直接使用するため、/ etc /resolv.confにあるDNSサーバーの順序を使用します。
ただし、ping(8)は、scutil--dnsを介して一覧表示できる結果を使用してクエリを注文する「スーパーDNS検索クライアント」を使用する内部MacOSX名前解決システムを使用します。
Sudo killall -INFO mDNSResponder
を実行してから、/var/log/system.log
を調べると、キャッシュされている内容を確認できます。
ほとんどのアプリケーションはDNSクライアントサービスに依存します(まあ、それらはサービスを使用するOSに依存しています...)-私はそれがまだ実行されていることを再確認します。問題が発生した場合は、サービスを再起動することもできます。
DNSキャッシュをフラッシュすることもできますが、一部のアプリケーション(特にWebブラウザー)はDNSエントリを内部的にキャッシュするため、それらも再起動する必要がある場合があることに注意してください。
ipconfig /flushdns
最後に、マルウェアが原因で事態が悪化する可能性があります。多くのマルウェアがDNSまたは特定のホストを乗っ取ります。おそらくそれもチェックする価値があります。