Porque é que o 'ping' não consegue resolver um nome quando o 'nslookup' funciona bem?

Creio que o nslookup abre uma ligação winsock no porto DNS e emite uma consulta, ao passo que o ping utiliza o serviço DNS Client. Pode tentar parar este serviço e ver se isto faz diferença.

Alguns comandos que irão reinicializar vários estados de rede :

Reinicializar entradas WINSOCK para os padrões de instalação : netsh winsock reset catalog Reinicializar a pilha TCP/IP para os padrões de instalação : netsh int ip reset reset.log Flush DNS resolver cache : ipconfig /flushdns Renovar o registo de clientes DNS e actualizar os alugueres DHCP : ipconfig /registerdns Flush tabela de encaminhamento : route /f (reiniciar necessário)

Tente fazer “ping” com o nome da pessoa, seguido de um ponto. Assim, em vez de ping wolfman use ping wolfman.

Isso deve fazê-lo resolver sem ter de fazer soluções com ficheiros de anfitriões, etc.

Experimente o ipconfig /displaydns e procure o lobisomem. Se estiver em cache como “name does not exist” (possivelmente devido a uma pesquisa anterior intermitente e falhada), pode lavar a cache com ipconfig /flushdns.

nslookup não utiliza a cache, mas consulta directamente o servidor DNS.

Tente adicionar . aos sufixos DNS para essa ligação. Isto é, vá para:

1. Estado Ethernet
2. Clique em Properties
3. Protocolo Internet Versão 4
4. Clique em Propriedades
5. Clique em Avançado
6. Anexe estes DNS suficientes (em ordem)
7. Adicione . como sufixo.

Os mesmos passos são ilustrados no seguinte screenshot:

Isto deve fazer ping wolfman funcionar.

Explicação

nslookup wolfman (name server lookup: wolfman) envia o hostname (wolfman) para o DNS (domain name system) para obter o endereço IP correspondente. Este é o único propósito do comando nslookup. Isto já funciona, pelo que verificámos que o DNS funciona e que wolfman corresponde efectivamente a um endereço IP.

Em contraste, ping wolfman precisa de fazer duas coisas:

1. Obter o IP a que o hostname (wolfman) corresponde.
2. Enviar pacotes para o IP e ouvir a resposta

No Windows (mesmo versões recentes como o Windows 10), o primeiro passo pode facilmente falhar. Por uma questão de compatibilidade com versões anteriores, o Windows suporta vários métodos de resolução de nomes de hosts (hosts file, DNS, NetBIOS/WINS, LMHOST file).

Infelizmente, parece que o comando ping do Windows nem sempre tenta uma pesquisa no DNS. Não conheço as condições específicas que desencadeiam este comportamento.

Felizmente, podemos forçar o Windows a fazer uma pesquisa DNS usando um FQDN (nome de domínio totalmente qualificado). Na prática, fazemos isto através da sufixação de um ponto . no nome da máquina: wolfman.. Experimente o ping wolfman. e verifique se funciona.

O passo final é forçar o Windows a anexar este ponto em si. Já mostrei como fazer isto no início desta resposta.

nslookup funciona de forma diferente dos outros comandos quando se resolvem nomes/ endereços IP no Windows.

O método resolução normal no Windows é o seguinte:

1. O cliente verifica se o nome consultado é o seu próprio nome.
2. O cliente pesquisa então um ficheiro Hosts local, uma lista de endereços IP e nomes armazenados no computador local.
3. Os servidores DNS (Domain Name System) são consultados.
4. Se o nome ainda não estiver resolvido, é utilizada a sequência de resolução de nomes NetBIOS como backup. Esta ordem pode ser alterada configurando o tipo de nó NetBIOS do cliente.

nslookup por outro lado é utilizado para testar Servidores de Nomes de Domínio.

Lutei com uma questão semelhante e tentei a solução sugerida por @harrymc. Encontrei o que eventualmente parece (pelo menos um pouco) funcionar no fórum da microsoft technet nslookup funciona mas nada mais tem DNS no PC independente Win7 )

Aqui está a citação:

… tente usar o comando abaixo para limpar e reiniciar uma cache de resolver clientes para teste.

ipconfig /flushdns

ipconfig /registerdns

Por favor, consulte o link abaixo para mais detalhes. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

Então basicamente o que faltava para mim era ipconfig /registerdns

Ainda hoje tivemos a mesma questão, mas a solução foi diferente. Por isso pensei, eu acrescentaria para referência, pois este foi o resultado mais procurado.

• Problem : ping não vai resolver um nome de anfitrião, mas nslookup pode. (Observado em 2 hosts Windows Server 2012 R2 diferentes.)
• Causa : (Para cada anfitrião) O anfitrião tem mais do que uma DNI ligada e existem multiplas gateways por defeito* configuradas.
• Solução* : (Para cada anfitrião) Remover a gateway por defeito da configuração de todas as DNIs excepto uma, pelo que volta a haver somente uma gateway por defeito*.

Talvez wolfman.company.com esteja listado no C:\system32\drivers\drivers\etc\sts ?

nslookup ultrapassa esse ficheiro e pede sempre DNS, enquanto ping e outras ferramentas procuram primeiro no ficheiro “hosts”, depois no DNS.

Eu tinha o mesmo problema num sistema Windows 2012R2 (=8.1), e tentei todas as sugestões acima, mas nenhuma delas o resolveria: - Pingingar o nome totalmente qualificado funcionou. - Pingar o nome não qualificado não funcionou. - Ambos funcionaram em vários outros sistemas, que tinham o mesmo SO e aparentemente a mesma configuração.
- Todos os sufixos de pesquisa necessários estavam lá. (Note que algumas das correcções propostas, como a alternativa para as consultas multi-label, são obviamente irrelevantes, uma vez que o nome não qualificado tem apenas uma parte)

• Depois reparei que o sistema alvo que estava a tentar ping NÃO tinha um endereço IPv6. Então tentei “ping -4 unqualified\name”, e bingo! isto funcionou. Então, por alguma razão, neste sistema apenas, ping apenas tentou resolver o nome não qualificado -> endereço IPv6, e não o nome não qualificado ->IPv4. Para mim a solução foi desactivar o IPv6 completamente, pois não preciso dele de todo. Mas estaria realmente interessado em encontrar uma forma mais suave de dizer ao ping (ou presumivelmente ao serviço cliente DNS) para tentar resolver tanto endereços IPv4 como IPv6.

Estava a tentar perceber porque é que num computador ganho 7 posso usar o ping server que funciona, e no outro não consegue resolver o server. No entanto ambos podiam ping server.lan o que eu não percebi bem.

Acontece que eu tinha mexido em algumas definições (sufixos DNS) para não ter que usar FQDNs enquanto usava a VPN de trabalho. Tive de ir adicionar o meu .lan local a esses sufixos para que ambos os computadores actuassem da mesma forma.

Vá ao Painel de Controlo > Network and Internet > Network Connections e clique com o botão direito do rato na sua ligação de rede e clique em Properties. Clique em Internet Protocol Versão 4 e clique no botão Propriedades. Depois o botão Avançado… nesta nova janela. Vá para o separador DNS, aqui é onde eu tinha adicionado um sufixo DNS para o meu trabalho mas também precisava de um para as minhas ligações domésticas normais.

Também me deparei com esta questão. A forma mais “fácil” de a resolver para mim foi simplesmente adicionar um . ao fim do nome da pessoa. No entanto, isto é bastante irritante. A maioria das redes não precisa disto. Prefiro não ter de dizer a toda a gente na rede para fazer isto quando precisam de aceder ao mesmo recurso.

Eu estava a olhar para a sugestão de Frederik Aalund como uma solução possível e reparei que eles sugeriram mudar da opção padrão “Append primary and connection specific DNS suffixes”. Isto fez-me pensar que talvez a minha rede estivesse simplesmente ligeiramente mal configurada.

Olhando para as minhas definições DD-WRT, o “Domínio LAN” foi deixado por definir. Configurar isso para uma string arbitrária parece ter resolvido este problema para todos os clientes da minha rede sem ter uma configuração especial em cada máquina, a solução que eu queria! :)

Estou a apanhar isto porque me incomodou no último ano e talvez tenha encontrado uma solução.

Para mim pareceu-me que algum sistema de dns-caching dentro das janelas do cliente está avariado. Windows 7 e 8.1 são afectados por isto… já não se pode dizer muito sobre o Windows XP. ping não resolve o nome. não é a parte do icmp que é importante mas sim a parte da resolução do nome). nslookup foi concebido para consultar o nameserver e faz exactamente isso e não há resolução de nomes no windows.

Reiniciar o serviço dnscache ajudou sempre. Mas como eu desabilitei o IPv6* em *todas as interfaces cliente, o problema já não ocorreu.

Cheers!

A adição de uma entrada no ficheiro c:/windows/system32/drivers/etc/hosts poderá corrigi-la.

encontrei isto quando migramos para o windows 7 a partir do windows XP, o problema estava relacionado com um problema de DNS Query Multi Label do Windows 7.

Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries - ver: http://computerstepbystep.com/allow_dns_suffix_appending_to_unqualified_multi_label_name_queries.html

Espero que isto ajude

Se em mac os x pode ser um problema DNS Cache:

Dump the cache

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

Posso estar enganado porque se baseia nos meus dias há muito esquecidos do NT4 ressource-kit.

Como tarifa posso lembrar que o PING usa Netbios/WINS e DNS (nessa ordem, pelo menos se você não especificar um FQDN).

WINS desapareceu há muitos anos, mas você ainda pode ter o Netbios habilitado na sua interface e o PING, portanto, pode usar netbios que pode não lhe dar nenhum resultado. Especialmente se o tráfego estiver passando por um roteador em algum lugar.

Basta desativar a Netbios e o Ping usarão o DNS como primeira prioridade e anexarão o DNS Surffic registrado na interface ao seu hostname.

Tente limpar o conteúdo da seguinte chave:

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

e depois reinicie o serviço “DNS Cache”.

Se isso ajudar, procure em Group Policy Management Console duas políticas chamadas “DirectAccess Client Settings” e “DirectAccess Server Settings”. Verifique se estão configuradas correctamente ou se são mesmo necessárias no seu cenário. Por vezes são criadas automaticamente com certas definições para a função de Routing e Remote Access num servidor e esta foi a causa do problema da nossa parte. http://virot.eu/manually-remove-direct-access-from-a-client/

Eu tinha o mesmo problema e afinal outra máquina tinha o mesmo endereço IP, e isso estava a causá-lo.

Mudou o IP de volta para DHCP e tudo estava a funcionar bem.

No meu caso, o que resolveu este problema foi adicionar o domínio do anfitrião que eu estava a tentar usar a uma opção de política de grupo chamada “DNS Suffix Search List”.

O procedimento, em suma, é este: Abrir gpedit.msc e navegar para Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, configurá-lo para “Enabled” e adicionar o nome do domínio à lista (a lista está vazia por defeito).

Uma descrição mais detalhada destes passos pode ser encontrada aqui

Nenhuma das soluções aqui funcionou para mim. O que funcionou para mim foi a reconexão com o vpn do meu trabalho usando o OpenVPN. Depois de desligar tudo continuou a funcionar.

Acredito que o problema estava relacionado com a energia a faltar enquanto o meu computador estava ligado com o OpenVPN. A única forma de descobrir isto foi utilizando a WireShark. Notei que os IPs de destino de todas as consultas iam para os IPs da rede interna do meu trabalho.

Acabei de ter este problema, e encontrei algo bastante peculiar, e consegui resolvê-lo Lol

Basicamente, se tiver alguma entrada no seu ficheiro anfitrião, que seja igual ao IP que o seu ping está a tentar resolver, ele irá falhar.

Por exemplo, se no seu DNS tiver um registo para www.example.com - 10.0.0.20, mas depois tiver uma entrada no ficheiro de hosts do seu cliente, 10.0.0.20 somethingelse.com, não poderá pingar www.example.com

Strange huh

ping utiliza o protocolo ICMP, especificamente o ‘Echo Request’ e o ‘Echo Reply’.

muitas redes desactivam os utilitários ICMP a fim de evitar ataques ou o scan básico da rede. Encontrei muitos roteadores que você compra vêm com uma configuração para desativar o ping e como utilitários habilitados por padrão.

você pode encontrar mais sobre o ICMP aqui: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol