Hay varias referencias (comoDNS no puede resolver el nombre de host; nslookup puedeohttps://web.archive.org/web/20160525082756/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.htmlohttps://web.archive.org/web/20121113214415/http://cbfive.com/blog/post/PING-vs-NSLookup.aspx) que indican lo siguiente o algo similar, pero no dan sugerencias de alternativas a utilizar:
La razón por la que ping no puede resolver el nombre de host pero nslookup sí puede es porque nslookup es una herramienta de bajo nivel que omite el cliente DNS de Windows. Utiliza cualquier servidor DNS que usted le indique (el primero por defecto) y realiza la consulta sobre la marcha.
Mi pregunta es ¿cómo puedoa mano¿Probar el cliente DNS para verificar un registro SRV? ¿Hay alguna forma de ver la información DNS que intenta utilizar? No puedo instalar Wireshark en todos los servidores de todos los entornos, por lo que estoy buscando otra forma de solucionar el problema. Supongo que la respuesta es "no", de lo contrario, ¿por qué usaríamos nslookup (por defectuoso que sea)? Obviamente no puedo usar ping para un registro SRV.
Editado con hallazgos actualizados: las consultas UDP son demasiado largas, por lo que la respuesta DNS con el indicador truncado se envía al cliente, por lo que se debe realizar una consulta TCP. El siguiente paquete después de la consulta DNS de TCP es (desde TargetDNS al cliente): "segmento TCP de una PDU reensamblada" (que parece contener información de respuesta), y luego es diferente según el escenario:
- Consulta Nslookup: con la consulta nslookup en realidad hay un paquete de respuesta DNS con la información.
- ApplicationX (que creo que usa el cliente DNS de Windows): consulta del cliente DNS de Windows, no hay ningún paquete de respuesta DNS (es decir, como si se hubiera perdido el otro paquete TCP)
- No hay nada en la caché DNS (ipconfig /displaydns) ni en la caché del servidor DNS del cliente para el registro SRV (ni siquiera un negativo).
Esto demuestra, como era de esperar, que el cliente DNS y nslookup obtienen resultados diferentes, pero ¿qué están haciendo exactamente de manera diferente (descontar hosts, lmhosts, agregar sufijos de búsqueda DNS, etc.)? Están utilizando los mismos servidores DNS (como lo demuestra Wireshark). ¿Cómo puedo delimitar dónde radica la falla?
Respuesta1
Su comprensión es correcta: nslookup
actúa como un cliente DNS en sí mismo, independientemente de lo que hace el sistema operativo en nombre de las aplicaciones típicas.
El cmdlet de Powershell Resolve-DnsName
, por otro lado, utiliza el cliente DNS de Windows subyacente. Por lo tanto, esta es una herramienta que se puede utilizar para activar el comportamiento normal del sistema operativo para búsquedas de DNS (u otras fuentes, ¡a pesar del nombre!), por separado de su aplicación.
Por ejemplo, algo así como ejemplo de SRV
búsqueda:
Resolve-DnsName -Type SRV _sip._tcp.example.com
Nota al margen:
El comportamiento de nslookup
y similares (generalmente dig
es la herramienta elegida en esta categoría) útil para investigar el comportamiento de DNS, específicamente porque el entorno local no afecta los resultados, pero al mismo tiempo hace que estas herramientas no sean adecuadas para investigar el comportamiento. del entorno del sistema operativo local.