Почему 'ping' не может разрешить имя, когда 'nslookup' работает нормально?

Я считаю, что nslookup открывает winsock соединение на DNS порту и выдает запрос, в то время как ping использует службу DNS Client. Вы можете попробовать остановить эту службу и посмотреть, имеет ли это значение.

Некоторые команды, которые заново инициализируют различные состояния сети :

Сброс записей WINSOCK для установки по умолчанию : netsh winsock reset catalog Сброс TCP/IP стека для установки по умолчанию : netsh int ip reset reset.log Флеш кэш DNS resolver : ipconfig /flushdns Обновить регистрацию DNS клиента и обновить аренду DHCP : ipconfig /registerdns Флеш-таблица маршрутизации : route /f (требуется перезагрузка)

Попробуй пинг с именем хозяина, за которым следует точка. Поэтому вместо ping wolfman используйте ping wolfman.

. Это позволит вам разрешить проблему без обходных путей с файлами хостов и т.д.

Попробуйте ipconfig /displaydns и ищите Вульфмана. Если он кэшируется как “имя не существует” (возможно, из-за предыдущего прерывистого неудачного поиска), вы можете промыть кэш с помощью ipconfig /flushdns.

nslookup не использует кэш, а запрашивает DNS-сервер напрямую.

Попробуйте добавить . к DNS суффиксам для этого соединения. Т.е. перейдите к:

1. Статус Ethernet
2. Нажмите Свойства
3. Интернет протокол версии 4
4. Нажмите Свойства
5. Нажмите Дополнительно
6. Добавьте эти DNS достаточные (по порядку)
7. Добавьте . в качестве суффикса.

Те же самые шаги проиллюстрированы на следующем скриншоте:

Это должно заставить ping wolfman работать.

Объяснение

nslookup wolfman (поиск сервера имен: wolfman) посылает имя хоста (wolfman) в DNS (система доменных имен) для получения соответствующего IP-адреса. Это единственная цель команды nslookup. Это уже работает, поэтому мы проверили, что DNS работает и что wolfman действительно соответствует IP адресу.

В отличие от этого, ping wolfman нужно сделать две вещи:

1. Получить IP, которому соответствует имя хоста (wolfman).

2. Отправка пакетов на IP и прослушивание ответа

On Windows (даже в последних версиях, таких как Windows 10), первый шаг может легко провалиться. Для обратной совместимости Windows поддерживает различные методы разрешения имен хостов (hosts file, DNS, NetBIOS/WINS, LMHOST file).

К сожалению, кажется, что команда Windows’ ping не всегда пытается выполнить DNS поиск. Я не знаю конкретных условий, которые вызывают такое поведение.

К счастью, мы можем заставить Windows выполнить DNS поиск с помощью FQDN (полное доменное имя). На практике мы делаем это с помощью суффикса . к имени хоста: wolfman.. Попробуйте ping wolfman. и убедитесь, что она работает.

Последним шагом будет заставить Windows добавить эту точку. Я уже показывал, как это сделать в начале этого ответа.

nslookup работает иначе, чем другие команды при разрешении имен/IP адресов в Windows.

Метод обычного разрешения в Windows выглядит следующим образом:

1. Клиент проверяет, является ли искомое имя его собственным.

2. Затем клиент ищет локальный файл Hosts, список IP-адресов и имен, хранящихся на локальном компьютере.

3. Опрашиваются серверы системы доменных имен (DNS).

4. Если имя все еще не разрешено, в качестве резервной копии используется последовательность разрешения имен NetBIOS. Этот порядок можно изменить, настроив тип узла NetBIOS клиента.

nslookup, с другой стороны, используется для тестирования серверов доменных имен. .

Я боролся с подобным вопросом и попробовал решение, предложенное @harrymc. Я нашел то, что, в конечном счете, кажется (по крайней мере, несколько) работает на форуме микрософт nslookup работает, но ничто другое не имеет DNS на автономном Win7 PC )

Вот цитата:

… попробуйте использовать нижеприведенную команду для прошивки и сброса кэша резольвера клиента для тестирования.

ipconfig /flushdns

ipconfig /registerdns

Пожалуйста, обратитесь к ссылке ниже для получения более подробной информации. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

Так что в основном мне не хватало ipconfig /registerdns.

Буквально сегодня у нас был same issue, но solution was different. Поэтому я решил добавить его для справки, так как это был самый верхний результат поиска.

• Problem : ping не будет разрешать имя хоста, но nslookup может. (Наблюдается на 2-х разных R2 хостах Windows Server 2012)
• Причина : (Для каждого хоста) На хосте подключено более одной сетевой карты и настроены множество шлюзов по умолчанию.
• Решение : (Для каждого хоста) Извлеките шлюз по умолчанию из конфигурации всех сетевых карт, кроме одной, таким образом, будут перезагружены только один шлюз по умолчанию.

Может быть, wolfman.company.com указан в C:\Windows\system32\drivers\etc\hosts ?

nslookup обходит этот файл и всегда запрашивает DNS, в то время как ping и другие инструменты сначала ищут в файле “hosts”, а затем в DNS.

У меня была та же проблема на системе Windows 2012R2 (=8.1), и я перепробовал все вышеперечисленные предложения, но ни одно из них не исправило ее: - Пинг полностью квалифицированного имени работал. - Пинг неквалифицированного имени не работал. - Оба работали на нескольких других системах, которые имели ту же самую операционную систему и, очевидно, ту же самую конфигурацию.
- Все необходимые строки поиска суффиксов были там. (Обратите внимание, что некоторые из предложенных исправлений, такие как обходной путь для многомаркировочных запросов, очевидно, не имеют значения, так как неквалифицированное имя имеет только одну часть)

• Тогда я заметил, что целевая система, которую я пытался пинговать, НЕ имела IPv6 адреса. Поэтому я попробовал “ping -4 unqualified_name”, и бинго! это сработало. По какой-то причине, только в этой системе, ping пытался разрешить только неквалифицированное имя>IPv6 адрес, а не не неквалифицированное имя>IPv4. Для меня исправление заключалось в полном отключении IPv6, так как он мне вообще не нужен. Но мне было бы очень интересно найти более щадящий способ сказать ping (или, предположительно, службе DNS-клиента), чтобы попытаться разрешить IPv4 и IPv6 адреса.

Я пытался выяснить, почему на одном выигранном компьютере я могу использовать ping server, который работает, а на другом он не может разрешить server. Однако и тот, и другой могут пинговать server.lan, что я не совсем понял.

Оказывается, я подтасовывал некоторые настройки (DNS суффиксы), чтобы не использовать FQDN при использовании рабочего VPN. Мне нужно было добавить мои локальные .lan к этим суффиксам, чтобы оба компьютера работали одинаково.

Перейдите в панель управления > Сеть и Интернет > Сетевые подключения и щелкните правой кнопкой мыши на вашем сетевом подключении и выберите Properties. Нажмите Интернет протокол версии 4 и нажмите кнопку Свойства. Затем нажмите кнопку Дополнительно… в этом новом окне. Перейдите в закладку DNS, здесь я добавил DNS суффикс для своей работы, но он также необходим для моих обычных домашних подключений.

Я тоже наткнулся на этот вопрос. Самым простым способом исправить это для меня было просто добавить . в конец имени хоста. Однако это довольно раздражает. Большинство сетей не требуют этого. Я бы не хотел говорить всем остальным в сети делать это, когда им нужен доступ к одному и тому же ресурсу.

Я рассматривал предложение Фредерика Аалунда (Frederik Aalund) в качестве возможного решения и заметил, что они предложили перейти от стандартной опции “Добавить первичные DNS суффиксы и DNS суффиксы, специфичные для подключения”. Это заставило меня подумать, что, возможно, моя сеть была просто слегка неправильно настроена.

Глядя на свои настройки DD-WRT, “LAN Domain” был оставлен не настроенным. Установка произвольной строки, кажется, исправила эту проблему для всех клиентов в моей сети без специальной настройки на каждой машине, решение, которое я хотел! :)

Я поднимаю этот вопрос, потому что это беспокоило меня в прошлом году, и, возможно, я нашел обходной путь.

Для меня казалось, что какая-то dns-кэширующая система внутри windows клиента неисправна. Windows 7 и 8.1 пострадали от этого… не может больше говорить о Windows XP. ping не разрешает имя. важна не icmp-часть, а разрешающая часть имени). nslookup предназначен для запроса к серверу имен и делает именно это, и никаких windows name-hierarchy-разрешение имени.

Перезапуск службы dnscache помог каждый раз. Но так как я выключил IPv6 на всех клиентских интерфейсах, проблема больше не возникала.

За Ваше здоровье!

Добавление записи в файл c:/windows/system32/drivers/etc/hosts может исправить это.

Я столкнулся с этим, когда мы перешли в Windows 7 из windows XP, проблема была связана с вопросом многомаркетичного DNS-запроса в Windows 7.

Разрешить суффикс DNS, добавляемый к неквалифицированным запросам многомаркетичных имен - смотрите: _COPY5_dns_suffix_appending_to\unqualified_multi_label_name_queries.html

Надеюсь, это поможет

Если на mac os x это может быть проблема с DNS кэшем:

Дампа кэша

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

Я могу ошибаться на этот счет, потому что он основан на моих давно забытых днях NT4 ressource-kit.

В качестве тарифного плана я могу вспомнить, что PING использует Netbios/WINS и DNS (в таком порядке, по крайней мере, если вы не укажете FQDN).

WINS ушло много лет назад, но у вас все еще может быть включена Netbios на вашем интерфейсе, и поэтому PING может использовать netbios, который может и не дать вам никакого результата. Особенно если трафик где-то проходит через маршрутизатор.

Просто отключите Netbios и Ping будут использовать DNS в качестве приоритета и добавлять зарегистрированный DNS трафик на интерфейсе к вашему имени хоста.

Только что на клиенте Windows 7, подключенном к домену, эта проблема оказалась неправильными параметрами DirectAccess в реестре.

Попробуйте очистить содержимое следующего ключа:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig

, а затем перезапустите службу ‘DNS Cache’.

Если это поможет, посмотрите в консоли управления групповыми политиками две политики под названием ‘DirectAccess Client Settings’ и ‘DirectAccess Server Settings’. Проверьте, правильно ли они настроены или даже необходимы в вашем сценарии. Иногда они создаются автоматически с определенными параметрами для роли маршрутизации и удаленного доступа на сервере, и это было причиной проблемы с нашей стороны. http://virot.eu/manually-remove-direct-access-from-a-client/

У меня была та же проблема, и оказалось, что у другой машины был тот же самый IP-адрес, и это ее и вызвало.

Сменили IP обратно на DHCP, и все работало нормально.

В моем случае решением этой проблемы было добавление домена узла, который я пытался опросить с помощью ping, в опцию групповой политики под названием “DNS Suffix Search List”.

Процедура вкратце сводится к следующему: Откройте gpedit.msc и перейдите к Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, установите “Enabled” и добавьте доменное имя в список (список пуст по умолчанию).

Более подробное описание этих шагов можно найти здесь

Ни одно из решений здесь мне не помогло. Что работало для меня, так это переподключение к vpn моей работы с помощью OpenVPN. Затем после отключения все продолжило работать.

я считаю, что проблема была связана с отключением питания, когда мой компьютер был подключен к openVPN. Единственный способ выяснить это - использовать WireShark. Я заметил, что IP-адреса назначения для всех запросов были направлены на IP-адреса внутренней сети моей работы.

У меня только что возникла эта проблема, и я нашел кое-что довольно необычное, и мне удалось исправить ее Lol

В общем, если у вас есть какие-то записи в файле hosts, которые совпадают с IP, на который пытается разрешить ваш ping, то это будет неудачно.

Например, если в вашем DNS есть запись для www.example.com - 10.0.0.20, но тогда в файле hosts вашего клиента, 10.0.0.20 somethingelse.com, вы не сможете пинговать www.example.com

Странное хех.

ping использует ICMP протокол, а именно ‘Echo Request’ и ‘Echo Reply’.

многие сети отключают утилиты ICMP для предотвращения атак или базового сетевого сканирования. Я обнаружил, что многие маршрутизаторы, которые вы покупаете, поставляются с настройками для отключения ping и похожи на утилиты, включенные по умолчанию.

подробнее об ICMP можно найти здесь: _COPY18_Control_Message_Protocol