Existem várias referências (comoO DNS não consegue resolver o nome do host; nslookup podeouhttps://web.archive.org/web/20160525082756/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.htmlouhttps://web.archive.org/web/20121113214415/http://cbfive.com/blog/post/PING-vs-NSLookup.aspx) que afirmam o seguinte ou algo semelhante, mas não dão sugestões de alternativas de uso:
A razão pela qual o ping não consegue resolver o nome do host, mas o nslookup pode, é porque o nslookup é uma ferramenta de baixo nível que ignora o cliente DNS do Windows. Ele usa qualquer servidor DNS que você solicitar (o primeiro por padrão) e faz a consulta em tempo real.
Minha pergunta é: como possomanualmentetestar o cliente DNS para verificar um registro SRV? Existe uma maneira de ver as informações de DNS que ele tenta usar? Não consigo colocar o Wireshark em todos os servidores em todos os ambientes, por isso estou procurando outra maneira de solucionar problemas. Presumo que a resposta seja "não", caso contrário, por que usaríamos o nslookup (defeituoso como é). Obviamente não posso usar o ping para um registro SRV.
Editado com descobertas atualizadas: As consultas UDP são muito longas, então a resposta DNS com o sinalizador truncado é enviada ao cliente, portanto, uma consulta TCP precisa ser feita. O próximo pacote após a consulta TCP DNS é (do TargetDNS para o cliente): "segmento TCP de uma PDU remontada" (que parece conter informações de resposta) e é diferente dependendo do cenário:
- Consulta Nslookup - com a consulta nslookup há na verdade um pacote de resposta DNS com as informações
- ApplicationX (que acredito usar o cliente DNS do Windows) - consulta do cliente DNS do Windows, não há pacote de resposta DNS (ou seja, como se o outro pacote TCP tivesse sido perdido)
- Não há nada no cache DNS (ipconfig/displaydns) ou no cache do servidor DNS do cliente para o registro SRV (nem mesmo negativo).
Isso prova, sem surpresa, que o cliente DNS e o nslookup obtêm resultados diferentes, mas exatamente o que eles estão fazendo de diferente (descontando hosts, lmhosts, anexando sufixos de pesquisa DNS, etc.)? Eles estão usando os mesmos servidores DNS (conforme evidenciado pelo Wireshark). Como posso identificar onde está a falha?
Responder1
Seu entendimento está correto, pois nslookup
atua como um cliente DNS por si só, separadamente de tudo o que o sistema operacional faz em nome de aplicativos típicos.
O cmdlet Powershell Resolve-DnsName
, por outro lado, usa o cliente DNS do Windows subjacente. Assim, esta é uma ferramenta que pode ser usada para acionar o comportamento normal do sistema operacional para pesquisas de DNS (ou outras fontes, apesar do nome!), separadamente da sua aplicação.
Por exemplo, algo assim como exemplo de SRV
pesquisa:
Resolve-DnsName -Type SRV _sip._tcp.example.com
Nota lateral:
O comportamento de nslookup
e similares (geralmente dig
é a ferramenta preferida nesta categoria) é útil para investigar o comportamento do DNS, especificamente porque o ambiente local não afeta os resultados, mas ao mesmo tempo torna essas ferramentas inadequadas para investigar o comportamento do ambiente do sistema operacional local.