web-dev-qa-db-ja.com

DNSは個々のプロセスでどのように使用されますか?

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つのドメインに向かうと思います。

6
atroon

使用している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キャッシュをフラッシュするには:

  • 10.4:lookupd -flushcache
  • 10.5:dscacheutil -flushcache
  • 10.6: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

12
Chealion

最後に、10.6.3と 少しいじる のおかげで修正されました。基本的には、com.Apple.mDNSResponder.plistを変更してから、dnsresponderを再起動します。

私は間違っているかもしれませんが、指示は間違っていると思います。最初にSudo cpと書かれているところにSudo mvと言うべきです。

3
Dan Rosenstark

/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を調べると、キャッシュされている内容を確認できます。

1
Doug Harris

ほとんどのアプリケーションはDNSクライアントサービスに依存します(まあ、それらはサービスを使用するOSに依存しています...)-私はそれがまだ実行されていることを再確認します。問題が発生した場合は、サービスを再起動することもできます。

DNSキャッシュをフラッシュすることもできますが、一部のアプリケーション(特にWebブラウザー)はDNSエントリを内部的にキャッシュするため、それらも再起動する必要がある場合があることに注意してください。

ipconfig /flushdns

最後に、マルウェアが原因で事態が悪化する可能性があります。多くのマルウェアがDNSまたは特定のホストを乗っ取ります。おそらくそれもチェックする価値があります。

0
Goyuix