¿Por qué el 'ping' no puede resolver un nombre cuando 'nslookup' funciona bien?

Creo que nslookup abre una conexión winock en el puerto DNS y emite una consulta, mientras que ping utiliza el servicio de cliente DNS. Podría intentar detener este servicio y ver si esto hace una diferencia.

Algunos comandos que reiniciarán varios estados de red :

Restablecer entradas WINSOCK a los valores predeterminados de la instalación : netsh winsock reset catalog Restablecer pila TCP/IP a los valores predeterminados de la instalación : netsh int ip reset reset.log Limpiar caché de resolución DNS : ipconfig /flushdns Renovar registro de cliente DNS y refrescar arrendamientos DHCP : ipconfig /registerdns Limpiar tabla de enrutamiento : route /f (se requiere reinicio)

Intenta hacer un ping con el nombre del host seguido de un punto. Así que en lugar de ping wolfman usa ping wolfman.

Eso debería hacer que resuelvas sin tener que hacer arreglos con el archivo de hosts, etc.

Intenta con ipconfig /displaydns y busca el hombre lobo. Si está en la caché como “el nombre no existe” (posiblemente debido a una búsqueda previa intermitente fallida), puedes vaciar la caché con ipconfig /flushdns.

nslookup no usa la caché, sino que consulta directamente al servidor DNS.

Intenta añadir . a los sufijos del DNS para esa conexión. Es decir, ve a:

1. Estado de Ethernet
2. Haga clic en Propiedades
3. Protocolo de Internet versión 4
4. Haga clic en Propiedades
5. Haga clic en Avanzado
6. Haga clic en el botón “Aceptar”. Añadir estos DNS es suficiente (en orden)
7. Añada . como sufijo.

Los mismos pasos se ilustran en la siguiente captura de pantalla:

Esto debería hacer que ping wolfman funcione.

Explicación

nslookup wolfman (búsqueda de servidor de nombres: wolfman) envía el nombre de host (wolfman) al DNS (sistema de nombres de dominio) para obtener la dirección IP correspondiente. Este es el único propósito del comando nslookup. Esto ya funciona, por lo que hemos verificado que el DNS funciona y que wolfman corresponde efectivamente a una dirección IP.

Por el contrario, ping wolfman necesita hacer dos cosas:

1. Obtener la IP a la que corresponde el nombre de host (wolfman).
2. En Windows (incluso en versiones recientes como Windows 10), el primer paso puede fallar fácilmente. En aras de la compatibilidad con versiones anteriores, Windows soporta varios métodos de resolución de nombres de host (archivo de hosts, DNS, NetBIOS/WINS, archivo LMHOST).

Desafortunadamente, parece que el comando ping de Windows no siempre intenta una búsqueda de DNS. No conozco las condiciones específicas que desencadenan este comportamiento.

Afortunadamente, podemos forzar a Windows a hacer una búsqueda DNS usando un FQDN (nombre de dominio completamente calificado). En la práctica, lo hacemos añadiendo el sufijo . al nombre del host: wolfman.. Pruebe ping wolfman. y verifique que funciona.

El último paso es forzar a Windows a añadir este punto. Ya he mostrado cómo hacerlo al principio de esta respuesta.

nslookup funciona de forma diferente a otros comandos cuando se resuelven nombres/direcciones IP en Windows.

El método de resolución normal en Windows es el siguiente:

1. El cliente comprueba si el nombre consultado es el suyo propio.
2. El cliente entonces busca un archivo local de Hosts, una lista de direcciones IP y nombres almacenados en la computadora local.
4. Se consultan los servidores del Sistema de Nombres de Dominio (DNS).
5. Si el nombre sigue sin resolverse, se utiliza la secuencia de resolución de nombres NetBIOS como copia de seguridad. Este orden puede ser cambiado configurando el tipo de nodo NetBIOS del cliente.

nslookup por otro lado se usa para probar los servidores de nombres de dominio.

He luchado con un problema similar y he intentado la solución sugerida por @harrymc. Encontré lo que eventualmente parece (al menos algo) funcionar en el foro de microsoft technet nslookup funciona pero nada más tiene DNS en un PC independiente Win7 )

Aquí está la cita:

… intenta usar el comando de abajo para limpiar y reiniciar un caché de resolución de clientes para la prueba.

ipconfig /flushdns

ipconfig /registerdns

Por favor, consulta el siguiente enlace para más detalles. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

Así que básicamente lo que me faltaba era ipconfig /registerdns

Hoy mismo tuvimos el mismo problema, pero la solución fue diferente. Así que pensé en añadirlo como referencia ya que este fue el resultado más alto de la búsqueda.

• Problema : ping no resolverá un nombre de host, pero nslookup puede. (Observado en 2 diferentes hosts de Windows Server 2012 R2.)
• Cause : (Para cada host) El host tiene más de un NIC conectado y hay múltiples gateways predeterminados configurados.
• Solución : (Para cada host) Elimina la pasarela por defecto de la configuración de todos los NICs menos uno, por lo que queda sólo una pasarela por defecto.

Tal vez wolfman.company.com aparece en C:\NWindows32\Nconductores, etc.

nslookup pasa por alto ese archivo y siempre pregunta al DNS, mientras que ping y otras herramientas primero buscan en el archivo “hosts”, luego en el DNS.

Tuve el mismo problema en un sistema Windows 2012R2 (=8.1), e intenté todas las sugerencias anteriores, pero ninguna de ellas lo solucionó: - El ping del nombre completo funcionó. - El ping del nombre no completo no funcionó. - Ambos funcionaron en varios otros sistemas, que tenían el mismo sistema operativo y aparentemente la misma configuración.
- Todas las cadenas de búsqueda de sufijos necesarias estaban allí. (Note que algunas de las correcciones propuestas, como la solución para las consultas multi-etiquetas, son obviamente irrelevantes, ya que el nombre no calificado tiene sólo una parte).

Entonces noté que el sistema objetivo que estaba tratando de hacer ping NO tenía una dirección IPv6. Así que intenté “ping -4 nombreno cualificado”, y ¡bingo! esto funcionó. Así que por alguna razón, en este sistema solamente, el ping sólo intentó resolver nombre no cualificado->dirección IPv6, y no nombre no cualificado->IPv4. Para mí la solución fue deshabilitar IPv6 completamente ya que no lo necesito en absoluto. Pero estaría muy interesado en encontrar una forma más suave de decirle a ping (o presumiblemente al servicio de cliente DNS) que intente resolver tanto las direcciones IPv4 como las IPv6.

Estaba tratando de averiguar por qué en un ordenador de ganar 7 puedo usar ping server que funciona, y el otro no puede resolver server. Sin embargo ambos podían hacer ping server.lan lo cual no entendí bien.

Resulta que me había metido con algunas configuraciones (sufijos DNS) para no tener que usar FQDNs al usar el VPN de trabajo. Tuve que añadir mi local .lan a esos sufijos para que ambos ordenadores actuaran igual.

Ve al Panel de Control > Red e Internet \ ~ - Conexiones de red y haz clic derecho en tu conexión de red y pulsa Propiedades. Haga clic en Protocolo de Internet Versión 4 y presione el botón Propiedades. Luego el botón Avanzado… en esta nueva ventana. Ve a la pestaña DNS, aquí es donde había añadido un sufijo DNS para mi trabajo pero también necesitaba uno para mis conexiones normales de casa.

Yo también me encontré con este tema. La forma “más fácil” de arreglarlo para mí fue simplemente añadir un . al final del nombre del host. Sin embargo, esto es bastante molesto. La mayoría de las redes no requieren esto. Prefiero no tener que decirle a todos los demás en la red que hagan esto cuando necesitan acceder al mismo recurso.

Estuve mirando la sugerencia de Frederik Aalund como una posible solución y noté que sugirieron cambiar la opción por defecto de “Agregar sufijos DNS primarios y específicos de la conexión”. Esto me hizo pensar que tal vez mi red estaba simplemente ligeramente mal configurada.

Mirando mi configuración de DD-WRT, el “Dominio LAN” se dejó sin configurar. Configurarlo a una cadena arbitraria parece haber solucionado este problema para todos los clientes de mi red sin tener una configuración especial en cada máquina, ¡la solución que yo quería! :)

Estoy recogiendo esto porque me molestó el año pasado y tal vez encontré una solución.

Para mí parecía que algún sistema de dns-caching dentro del cliente de windows es defectuoso. Windows 7 y 8.1 están afectados por esto… ya no puede decir mucho sobre Windows XP. ping no resuelve el nombre. no es la parte de icmp que es importante sino la parte de resolución de nombres). nslookup está diseñado para consultar el servidor de nombres y hace exactamente eso y no resuelve la jerarquía de nombres de windows.

Reiniciar el servicio dnscache ayudó siempre. Pero desde que deshabilité IPv6 en todas las interfaces de cliente el problema no se produjo más.

¡Salud!

Añadir una entrada en el archivo c:/windows/system32/drivers/etc/hosts podría arreglarlo.

He encontrado esto cuando migramos a Windows 7 desde Windows XP, el problema estaba relacionado con un problema de consulta DNS multi-etiqueta de Windows 7.

Permitir que el sufijo DNS se añada a las consultas de nombres multi-etiqueta no cualificados - ver: http://computerstepbystep.com/allowdnssuffix_appending_to\Nunqualified_multi_label\N_name_queries.html

Espero que esto ayude

Si en mac os x puede ser un problema de caché de DNS:

Vaciar el caché

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

Podría estar equivocado en esto porque se basa en mis días de recurso de NT4 olvidado hace mucho tiempo.

Como tarifa puedo recordar que PING usa Netbios/WINS y DNS (en ese orden, al menos si no especificas un FQDN).

WINS se ha ido hace muchos años pero todavía puede tener Netbios habilitado en su interfaz y PING por lo tanto puede usar netbios que no le dará ningún resultado. Especialmente si el tráfico pasa por un router en algún lugar.

Sólo deshabilite Netbios y Ping usará DNS como primera prioridad y añadirá el DNS Surffic registrado en la interfaz a su nombre de host.

Acaba de aparecer este problema en un cliente de Windows 7 unido a un dominio que resultó ser una configuración incorrecta de DirectAccess en el registro.

Intenta borrar el contenido de la siguiente clave:

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

y luego reinicia el servicio ‘Caché DNS’.

Si eso ayuda, busca en la consola de administración de directivas de grupo dos políticas llamadas ‘Configuración del cliente de DirectAccess’ y ‘Configuración del servidor de DirectAccess’. Comprueba si están configuradas correctamente o incluso si son necesarias en tu escenario. A veces se crean automáticamente con ciertos ajustes para el rol de Enrutamiento y Acceso Remoto en un servidor y esto fue la causa del problema por nuestra parte. http://virot.eu/manually-remove-direct-access-from-a-client/

Tuve el mismo problema y resulta que otra máquina tenía la misma dirección IP, y eso lo estaba causando.

Cambié la IP de nuevo a DHCP y todo funcionaba bien.

En mi caso lo que resolvió este problema fue añadir el dominio del host que estaba intentando hacer ping a una opción de la política de grupo llamada “Lista de búsqueda de sufijos de DNS”.

El procedimiento en resumen es este: Abrir gpedit.msc y navegar hasta Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, configurarlo como “Habilitado” y añadir el nombre de dominio a la lista (la lista está vacía por defecto).

Una descripción más detallada de estos pasos se puede encontrar aquí

Ninguna de las soluciones aquí me funcionó. Lo que sí me funcionó fue reconectarme a la vpn de mi trabajo usando OpenVPN. Luego, después de desconectar todo siguió funcionando.

Creo que el problema estaba relacionado con el apagón mientras mi ordenador estaba conectado con openVPN. La única manera de resolver esto fue usando WireShark. Me di cuenta de que las IPs de destino de todas las consultas iban a las IPs de la red interna de mi trabajo.

Acabo de tener este problema, y encontré algo bastante peculiar, y me las arreglé para solucionarlo Lol

Básicamente, si tienes alguna entrada en el archivo de tu host, que es la misma que la IP que tu ping está tratando de resolver, fallará.

Por ejemplo, si en tu DNS, tienes un registro para www.example.com - 10.0.0.20, pero luego tienes una entrada en el archivo de hosts de tu cliente, 10.0.0.20 algoelse.com, no podrás hacer ping a www.example.com

Extraño eh

ping utiliza el protocolo ICMP, específicamente la “Solicitud de Eco” y la “Respuesta de Eco”.

muchas redes deshabilitan las utilidades ICMP para prevenir ataques o escaneo básico de la red. He encontrado que muchos enrutadores que compran vienen con una configuración para deshabilitar el ping y como utilidades habilitadas por defecto.

puedes encontrar más acerca de ICMP aquí: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol