Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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:
- Compruebe la memoria caché.
- Compruebe el archivo Hosts.
- 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.