Compartir a través de

Solución de problemas de resolución de nombres de cliente DNS

Este artículo ayuda a solucionar problemas de resolución de nombres de cliente del sistema de nombres de dominio (DNS).

Los problemas de resolución del sistema de nombres de dominio (DNS) pueden producirse para las tres causas principales siguientes:

  • Problemas o configuraciones del cliente DNS.
  • Problemas o configuraciones del servidor DNS.
  • Dispositivos o configuraciones intermedios entre un cliente DNS y un servidor DNS, o entre un servidor DNS y solucionadores externos (como sugerencias raíz, reenviadores y reenviadores condicionales), lo que podría requerir una investigación adicional.

Nota:

Este artículo se centra en los problemas de resolución de DNS causados por problemas de cliente DNS o configuraciones. Para obtener información sobre los problemas del servidor DNS, consulte Solución de problemas de servidores DNS.

Los problemas de resolución de DNS pueden producirse en los escenarios siguientes:

Escenario 1: La regla de firewall bloquea las conexiones salientes en el puerto UDP 53

Supongamos que hay una regla de firewall de salida que bloquea las conexiones salientes en el puerto 53 del Protocolo de datagramas de usuario (UDP).

En este caso, al ejecutar el Resolve-DnsName contoso.com cmdlet de PowerShell con Wireshark en ejecución, recibirá el siguiente error:

resolve-dnsname : contoso.com : This operation returned because the timeout period expired
At line:1 char:1
+ resolve-dnsname contoso.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationTimeout: (contoso.com:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_TIMEOUT,Microsoft.DnsClient.Commands.ResolveDnsName

Al comprobar el seguimiento de Wireshark, no hay tráfico DNS saliente al controlador de dominio (DC).

En este caso, revise las reglas de Firewall de Windows y compruebe los productos de seguridad de terceros para las caídas de paquetes en el puerto UDP o protocolo de control de transmisión (TCP) 53.

Si observa una solicitud de resolución DNS sin respuesta, resulta útil recopilar seguimientos de Wireshark desde un conmutador mediante la creación de reflejo del puerto para confirmar que el paquete UDP dns dejó la máquina cliente. Las solicitudes son similares a las siguientes:

139 3.149039    10.0.1.10   10.0.1.2    DNS 71  Standard query 0xcdc6 A contoso.com
140 3.149192    10.0.1.10   10.0.1.2    DNS 71  Standard query 0x8168 AAAA contoso.com

Se trata de solicitudes de consulta estándar para el host A y la AAAA de host sin respuesta. Comprobar el seguimiento puede aislar el problema. Si ve el paquete UDP en el conmutador, significa que el paquete ya ha dejado la máquina cliente y el problema está más allá de la máquina cliente.

Escenario 2: Hay una entrada para el nombre de dominio en el archivo Hosts

Supongamos que el archivo Hosts ubicado en C:\Windows\System32\drivers\etc tiene una entrada para el nombre de dominio que desea resolver. Por ejemplo:

192.168.1.10 contoso.com

En este caso, al resolver el nombre contoso.com de dominio con Wireshark en ejecución, recibirá la siguiente salida:

PS C:\Windows\System32\drivers\etc> Resolve-DnsName contoso.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
contoso.com                                    A      60440 Answer     192.168.1.10

Además, no se puede detectar tráfico en Wireshark.

Esto se debe a que el cliente DNS usa la siguiente secuencia al resolver nombres:

  1. Compruebe la memoria caché.
  2. Compruebe el archivo Hosts.
  3. Envíe la consulta al servidor DNS.

Dado que hay una entrada en el archivo Hosts, el servicio de cliente DNS no consulta el servidor DNS.

Escenario 3: el cliente apunta a un servidor DNS incorrecto o inaccesible

Supongamos que el servidor DNS de la tarjeta de interfaz de red (NIC) del cliente DNS está configurado con la dirección IP de un servidor DNS inaccesible. La configuración de IP del cliente es similar al ejemplo siguiente:

IPv4 Address. . . . . . . . . . . : 10.0.1.10<Preferred>
Default Gateway . . . . . . . . . : 10.0.1.1
DNS Servers . . . . . . . . . . . : 192.168.0.1

Dado que el servidor DNS no es accesible, el cliente no recibe una respuesta, lo que hace que se agote el tiempo de espera de la consulta. Este tiempo de espera se puede observar en Wireshark. Las consultas estándar de DNS sin respuesta:

439 14.482923   10.0.1.10   192.168.0.1 DNS 71  Standard query 0xa384 A contoso.com
440 14.482923   10.0.1.10   192.168.0.1 DNS 71  Standard query 0x4fe0 AAAA contoso.com

En este caso, al ejecutar el Resolve-DnsName contoso.com cmdlet de PowerShell, recibirá la siguiente salida:

PS C:\Windows\System32\drivers\etc> Resolve-DnsName contoso.com
Resolve-DnsName : contoso.com : This operation returned because the timeout period expired
At line:1 char:1
+ Resolve-DnsName contoso.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationTimeout: (contoso.com:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_TIMEOUT,Microsoft.DnsClient.Commands.ResolveDnsName

Escenario 4: Varios servidores DNS están configurados en la NIC, algunos de los cuales no son accesibles

Supongamos que la configuración dns del cliente está configurada con algunos servidores DNS inaccesibles de la siguiente manera:

DNS Servers . . . . . . . . . . . : 192.168.0.1
                                    172.16.1.1
                                    192.168.1.20
                                    10.0.1.2

En este caso, cuando se realiza una resolución DNS mediante el Resolve-DnsName contoso.com cmdlet de PowerShell, todas esas direcciones de servidor DNS excepto 10.0.1.2 no son accesibles.

Por diseño, el cliente DNS comenzará a enviar esta consulta a los servidores DNS configurados en un orden específico y esperará una respuesta dentro de un período de gracia específico.

Este proceso se puede ver en Wireshark con el filtro dns.qry.name == contoso.com.

La salida de Wireshark muestra que la consulta tarda casi cuatro segundos en completarse. Desde una perspectiva de red, esta duración puede ser larga y puede provocar que algunas aplicaciones agoten el tiempo de espera.

30  03:56:58.634623 10.0.1.10   192.168.0.1  DNS 71  Standard query 0x9f32 A contoso.com
33  03:56:59.643171 10.0.1.10   172.16.1.1   DNS 71  Standard query 0x9f32 A contoso.com
38  03:57:02.646443 10.0.1.10   192.168.0.1  DNS 71  Standard query 0x9f32 A contoso.com
42  03:57:02.646556 10.0.1.10   172.16.1.1   DNS 71  Standard query 0x9f32 A contoso.com
43  03:57:02.646573 10.0.1.10   192.168.1.20 DNS 71  Standard query 0x9f32 A contoso.com
47  03:57:02.646684 10.0.1.10   10.0.1.2     DNS 71  Standard query 0x9f32 A contoso.com

Nota:

En este escenario, el uso nslookup no es aplicable y siempre producirá un error. Esto se debe nslookup a que usa nslookup.exe para ponerse en contacto solo con el servidor DNS principal configurado, que en este caso es 192.168.0.1.

Escenario 5: Lista de búsqueda de sufijos DNS largos

Supongamos que la lista de búsqueda de sufijos DNS en el cliente DNS está configurada de la siguiente manera:

Nota:

contoso.com es el sufijo DNS correcto.

DNS Suffix Search List. . . . . . : microsoft.com
                                    ms.com
                                    azure.com
                                    ms.local
                                    contoso.local
                                    contoso.com

En este caso, cuando se realiza una resolución de nombres mediante el Resolve-DnsName internal cmdlet de PowerShell, el cliente DNS anexará los sufijos DNS en orden, lo que podría provocar retrasos si la consulta necesaria es inferior en la lista. Mediante el filtro dns.qry.name contains internal en Wireshark, la consulta aparece de la siguiente manera:

116 04:33:38.164251 10.0.1.10   10.0.1.2    DNS 82  Standard query 0xc557 A internal.microsoft.com
120 04:33:38.177186 10.0.1.10   10.0.1.2    DNS 75  Standard query 0x0a4b A internal.ms.com
124 04:33:38.453625 10.0.1.10   10.0.1.2    DNS 78  Standard query 0x4245 A internal.azure.com
128 04:33:38.466154 10.0.1.10   10.0.1.2    DNS 77  Standard query 0xfaca A internal.ms.local
131 04:33:38.471033 10.0.1.10   10.0.1.2    DNS 82  Standard query 0xa9d6 A internal.contoso.local
136 04:33:38.476248 10.0.1.10   10.0.1.2    DNS 80  Standard query 0x611f A internal.contoso.com

Nota:

Si necesita probar una consulta específica, puede agregar un período final (.) al final. Por ejemplo: internal.contoso.com.

Medición del tiempo que tarda una consulta de resolución DNS

Para medir el tiempo necesario para que se complete una consulta de resolución DNS, ejecute el siguiente cmdlet de PowerShell:

Nota:

Un resultado bajo un segundo se considera aceptable.

(Measure-Command {Resolve-DnsName -Name contoso.com -Server <IP Address> -DnsOnly}).TotalMilliseconds

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.