「nslookup」が正常に機能するのに「ping」が名前を解決できないのはなぜですか？

私のWindows XPワークステーションでは、DNSで接続したいマシンを見つけることができますnslookup：

nslookup wolfman
Server: dns.company.com
Address: 192.168.1.38

Name: wolfman.company.com
Address: 192.168.1.178

しかし、そのマシンに接続しようとすると、マシンが見つからない（つまりDNSで検索できない）というエラーが表示されます。

C:\> ping wolfman
Ping request could not find host wolfman. Please check the name and try again.

IPアドレスを直接使用すると接続できます。

C:\> ping 192.168.1.178

Pinging 192.168.1.178 with 32 bytes of data:

Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=44ms TTL=126
Reply from 192.168.1.178: bytes=32 time=38ms TTL=126

hostsファイルにエントリを追加することでこれを回避できますが、なぜこれが起こっているのかを知りたいです。問題は一時的なもので、ほとんどの場合、マシンに正常に接続できます。

これはどのように可能ですか？

ETA：簡潔にするためにこれを省略しましたが、次のように求められました。

C:\> ping wolfman.company.com
Ping request could not find host wolfman.company.com. Please check the name and try again.

ETA：他のアプリケーションでも同じ結果が得られます。pingを試してみただけです。telnetが接続できず、Cygwinアプリは「unknown host wolfman」メッセージを出力します。

更新：wiresharkを使用して、ワークステーションがDNSルックアップを試行していないことがわかりました。「ホストが見つかりませんでした」というエラーメッセージを報告しているだけです。

nslookupはDNSポートでwinsock接続を開き、クエリを発行しますが、pingはDNSクライアントサービスを使用します。このサービスを試して停止し、これが違いを生むかどうかを確認できます。

さまざまなネットワーク状態を再初期化するいくつかのコマンド：

WINSOCKエントリをインストール時のデフォルトにnetsh winsock reset catalog
リセット：TCP / IPスタックをインストール時のデフォルトにリセット：netsh int ip reset reset.log
DNSリゾルバーキャッシュをフラッシュ：ipconfig /flushdns
DNSクライアント登録を更新し、DHCPリースを更新：ipconfig /registerdns
ルーティングテーブルをフラッシュ：（route /f 再起動が必要）

ホスト名の後にドットを続けてpingを試してください。ping wolfman使用する代わりにping wolfman.

これにより、hostsファイルなどで回避策を実行しなくても解決できます。

ipconfig /displaydnsウルフマンを試してみてください。「名前が存在しない」としてキャッシュされている場合（以前の断続的な検索失敗が原因である可能性があります）、キャッシュをでフラッシュできますipconfig /flushdns。

nslookup キャッシュを使用せず、DNSサーバーに直接クエリします。

.その接続のDNSサフィックスに追加してみてください。すなわち、に行きます：

1. イーサネットステータス
2. プロパティをクリック
3. インターネットプロトコルバージョン4
4. プロパティをクリック
5. 詳細設定をクリックします
6. これらのDNSで十分です（順番に）
7. .接尾辞として追加します。

次のスクリーンショットにも同じ手順が示されています。

これで動作するはずping wolfmanです。

説明

nslookup wolfman（ネームサーバールックアップ：wolfman）ホスト名（wolfman）をDNS（ドメインネームシステム）に送信して、対応するIPアドレスを取得します。これがnslookupコマンドの唯一の目的です。これはすでに機能しているため、DNSが機能し、wolfman実際にIPアドレスに対応していることを確認しました。

対照的に、ping wolfman2つのことを行う必要があります。

1. ホスト名（wolfman）が対応するIPを取得します。
2. パケットをIPに送信し、応答をリッスンします

Windows（Windows 10などの最近のバージョンでも）では、最初のステップは簡単に失敗する可能性があります。後方互換性のために、Windowsはホスト名解決のさまざまな方法（ホストファイル、DNS、NetBIOS / WINS、LMHOSTファイル）をサポートしています。

残念ながら、Windowsのpingコマンドは常にDNSルックアップを試行するとは限りません。この動作をトリガーする特定の条件はわかりません。

幸いなことに、FQDN（完全修飾ドメイン名）を使用して、WindowsにDNSルックアップを強制することができます。実際には.、ホスト名の末尾にドットを付けることでこれを行います：wolfman.。ping wolfman.動作することを確認してください。

最後のステップは、Windowsにこのドット自体を追加させることです。この回答の冒頭で、これを行う方法を既に示しました。

nslookup Windowsで名前/ IPアドレスを解決するとき、他のコマンドとは異なります。

Windowsでの通常の解決方法は次のとおりです。

1. クライアントは、照会された名前が独自のものであるかどうかを確認します。
2. 次に、クライアントはローカルホストファイル、ローカルコンピューターに保存されているIPアドレスと名前のリストを検索します。
3. ドメインネームシステム（DNS）サーバーが照会されます。
4. それでも名前が解決されない場合、NetBIOS名前解決シーケンスがバックアップとして使用されます。この順序は、クライアントのNetBIOSノードタイプを構成することで変更できます。

nslookup一方、ドメインネームサーバーのテストに使用されます。

私は同様の問題に苦労し、@ harrymcが提案する解決策を試しました。最終的に（少なくともある程度）マイクロソフトテクネットフォーラムで動作するように見えるものを見つけました（nslookupは動作しますが、スタンドアロンのWin7 PCにはDNSがありません）

引用は次のとおりです。

...以下のコマンドを使用して、テストのためにクライアントリゾルバーキャッシュをフラッシュしてリセットします。

ipconfig / flushdns

ipconfig / registerdns

詳細については、以下のリンクを参照してください。 http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

基本的に私に欠けていたのは ipconfig /registerdns

ちょうど今日、私たちは同じ問題を抱えていましたが、解決策は異なっていました。これが検索結果のトップであるため、参考のために追加すると思いました。

• 問題：pingホスト名は解決されませんが、解決nslookupできます。（2つの異なるWindows Server 2012 R2ホストで観察されます。）
• 原因：（ホストごとに）ホストに複数のNICが接続されており、複数のデフォルトゲートウェイが構成されています。
• 解決策：（各ホストについて）1つを除くすべてのNICの構成からデフォルトゲートウェイを削除します。そのため、デフォルトゲートウェイは1つだけ残っています。

たぶんwolfman.company.comはC：\ Windows \ system32 \ drivers \ etc \ hostsにリストされていますか？

nslookupはそのファイルをバイパスして常にDNSを要求しますが、pingなどのツールはまず「hosts」ファイルを検索し、次にDNSを検索します。

Windows 2012R2（= 8.1）システムでも同じ問題が発生し、上記のすべての提案を試みましたが、いずれも修正できませんでした。-
完全修飾名のPingが機能しました。
-修飾されていない名前をpingしませんでした。
-両方とも、同じOSと明らかに同じ構成を持つ他のいくつかのシステムで動作しました。
-必要なすべてのサフィックス検索文字列がそこにありました。
（修飾されていない名前には1つの部分しかないため、マルチラベルクエリの回避策など、提案された修正の一部は明らかに無関係です。）

次に、pingを実行しようとしているターゲットシステムにIPv6アドレスがないことに気付きました。それで、「ping -4 unqualified_name」とビンゴを試しました！これはうまくいきました。
そのため、何らかの理由で、このシステムでのみ、pingは非修飾名-> IPv4アドレスではなく、非修飾名-> IPv6アドレスのみを解決しようとしました。
私にとって修正は、IPv6をまったく必要としないので完全に無効にすることでした。しかし、ping（またはおそらくDNSクライアントサービス）にIPv4アドレスとIPv6アドレスの両方を解決するよう指示するより穏やかな方法を見つけることに本当に興味があります。

ファイルにエントリを追加c:/windows/system32/drivers/etc/hostsすると修正される場合があります。

私は1台のWindows 7コンピューターping serverで動作するコンピューターを使用でき、もう1台のコンピューターでは解決できない理由を把握しようとしていましたserver。しかし、どちらもserver.lan私にはよくわからなかったpingができました。

仕事用VPNの使用中にFQDNを使用する必要がないように、いくつかの設定（DNSサフィックス）を台無しにしていたことがわかりました。.lan両方のコンピューターを同じように動作させるために、これらのサフィックスにローカルを追加する必要がありました。

[コントロールパネル]> [ネットワークとインターネット]> [ネットワーク接続]に移動し、ネットワーク接続を右クリックして[プロパティ]をクリックします。[インターネットプロトコルバージョン4]をクリックし、[プロパティ]ボタンをクリックします。次に、この新しいウィンドウの[詳細設定...]ボタンをクリックします。[DNS]タブに移動します。これは、仕事用にDNSサフィックスを追加した場所ですが、通常のホーム接続にも必要です。

私もこの問題に出会いました。私にとってそれを修正する「最も簡単な」方法は、単に.ホスト名の最後にa を追加することでした。しかし、これはかなり面倒です。ほとんどのネットワークはこれを必要としません。同じリソースにアクセスする必要があるときに、ネットワーク上の他の全員にこれを行うように指示する必要はありません。

可能な解決策としてフレデリック・アーランドからの提案を見ていましたが、デフォルトの「プライマリおよび接続固有のDNSサフィックスを追加する」オプションから切り替えることを提案していることに気付きました。これにより、おそらく私のネットワークがわずかに誤って設定されていると思うようになりました。

DD-WRTの設定を見ると、「LANドメイン」は設定されていません。これを任意の文字列に設定すると、各マシンで特別な構成を行うことなく、ネットワーク上のすべてのクライアントでこの問題が修正されたようです。:)

Windows XPからWindows 7に移行したときにこの問題が発生しました。この問題はWindows 7マルチラベルDNSクエリの問題に関連していました。

修飾されていないマルチラベル名クエリへのDNSサフィックスの追加を許可する-参照：

http://computerstepbystep.com/allow_dns_suffix_appending_to_unqualified_multi_label_name_queries.html

お役に立てれば

Mac OS XでDNSキャッシュの問題である可能性がある場合：

キャッシュをダンプする

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

去年それが気になり、おそらく回避策を見つけたので、私はこれを取り上げています。

私にとっては、Windowsクライアント内のdns-caching-systemに欠陥があるようです。Windows 7および8.1はこれの影響を受けます... Windows XPについてはもはや語ることはできません。pingは名前を解決しません。重要なのはicmp部分ではなく、名前解決部分です）。nslookupは、ネームサーバーにクエリを実行するように設計されており、Windowsの名前階層解決をまったく行わず、まったく行いません。

dnscacheサービスを再起動すると、毎回役に立ちました。私は以来、しかし、IPv6を無効にすべてのクライアント・インタフェースの問題はもう発生しませんでした。

乾杯！

私が長い間忘れていたNT4リソースキットの時代に基づいているので、これは間違っているかもしれません。

運賃として、PINGはNetbios / WINSとDNSを使用することを思い出せます（少なくともFQDNを指定しない場合は、この順序で）。

WINSは何年も前になくなっていますが、インターフェイスでNetbiosが有効になっている可能性があるため、PINGは結果をもたらさないNetBIOSを使用する可能性があります。特に、トラフィックがどこかでルーターを通過している場合。

Netbiosを無効にすると、PingはDNSを最優先として使用し、登録済みのDNS Surfficをホスト名に追加します。

私はちょうどこの問題を抱えていて、非常に独特なものを見つけて、それをなんとか修正しましたLol

基本的に、ホストファイルにエントリがあり、pingが解決しようとしているIPと同じ場合、失敗します。

たとえば、DNSにwww.example.com-10.0.0.20のレコードがあるが、クライアントのホストファイル10.0.0.20 somethingelse.comにエントリがある場合、wwwにpingすることはできません。 .example.com

奇妙なハァッ

私の場合、この問題を解決したのは、pingしようとしていたホストのドメインを「DNSサフィックス検索リスト」というグループポリシーオプションに追加することでした。

手順の概要は次のとおりです。開いgpedit.mscてに移動しComputer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List、「有効」に設定して、ドメイン名をリストに追加します（デフォルトではリストは空です）。

これらの手順の詳細については、こちらをご覧ください

私は同じ問題を抱えていて、別のマシンに同じIPアドレスがあり、それが原因であることがわかりました。

IPをDHCPに戻し、すべてが正常に機能していました。

ここでの解決策はどれも役に立たなかった。私にとっては、OpenVPNを使用して仕事のVPNに再接続することができました。その後、切断後もすべてが機能し続けました。

この問題は、コンピューターがopenVPNに接続されているときに電源が切れたことに関連していると思います。私がこれを理解した唯一の方法は、WireSharkを使用することでした。すべてのクエリの宛先IPが、仕事の内部ネットワーク上のIPに送られていることに気付きました。

pingはICMPプロトコル、特に「エコー要求」と「エコー応答」を使用します。

多くのネットワークは、攻撃または基本的なネットワークスキャンを防ぐためにICMPユーティリティを無効にします。購入した多くのルーターには、pingを無効にする設定と、デフォルトで有効になっているユーティリティが付属していることがわかりました。

ICMPの詳細については、こちらをご覧ください。

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol