Cómo solucionar el error "el servidor DNS no responde"

Qué significa el error

Toda conexión empieza con una consulta. Tu dispositivo envía el nombre de host a un resolutor, normalmente tu router, tu proveedor de internet o un servicio público como 1.1.1.1, y espera una dirección IP. Si no llega respuesta dentro del tiempo límite, el sistema operativo reintenta, prueba el servidor secundario y al final se rinde. Windows ejecuta entonces su solucionador de problemas, que informa de que el servidor DNS no responde.

El texto señala al servidor, pero en realidad habla de una ruta. Cualquiera de estas situaciones produce el mismo mensaje: el resolutor está caído, el resolutor funciona pero es inalcanzable desde tu red, un cortafuegos descarta el puerto 53, la dirección configurada en tu adaptador es incorrecta o el router intermedio dejó de reenviar. El silencio es idéntico en los cinco casos.

Distínguelo de sus vecinos antes de empezar. Un resolutor que responde "ese nombre no existe" te da un NXDOMAIN, tratado en DNS_PROBE_FINISHED_NXDOMAIN. Un resolutor que responde despacio pero correctamente es otro problema distinto, y tiene su propia sección más abajo. Este error es el caso en el que no vuelve nada.

Por qué ocurre

• El router dejó de reenviar. Los routers domésticos ejecutan un pequeño reenviador de DNS que se atasca más a menudo que el resto del aparato, así que la red parece estar en línea y solo fallan las consultas de nombres.
• El servidor DNS configurado es incorrecto. Una dirección estática que quedó de una red antigua, o un servidor que ya se retiró de servicio.
• El resolutor del proveedor de internet tiene una caída o está sobrecargado y descarta consultas en lugar de responderlas.
• Un cortafuegos o una suite de seguridad bloquea el puerto 53. Algunos productos interceptan el DNS ellos mismos y lo cierran todo cuando su propio servicio no está en marcha.
• Una VPN conectada a medias. El túnel puso sus resolutores internos en tu adaptador y luego se cayó, dejando direcciones que solo son alcanzables dentro del túnel.
• IPv6 está configurado pero no se puede usar. El sistema prefiere un resolutor IPv6, no encuentra ruta hacia él y espera a que venza el tiempo límite antes de volver a IPv4.
• El servicio Cliente DNS de Windows está detenido o su caché está corrupta.
• Malware o una aplicación no deseada cambió el resolutor por una dirección que controla, y esa dirección después desaparece.
• La red exige iniciar sesión en un portal cautivo que todavía no has completado, así que todo el DNS saliente se pierde.

Cómo solucionarlo

Averigua si la red en sí funciona antes de tocar la configuración de DNS. ping 1.1.1.1 no usa resolución de nombres en absoluto. Si eso también falla, tienes un problema de conectividad, no de DNS. Si funciona mientras ping example.com falla, el DNS queda confirmado como la pieza rota y los pasos de abajo aplican.

Windows

1. Vacía la caché y reinicia el servicio cliente:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Mira qué está usando tu adaptador: ipconfig /all | findstr /C:"DNS Servers"
3. Configura en su lugar un resolutor público: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Prueba ese servidor concreto de forma directa: nslookup example.com 1.1.1.1
5. Restablece la pila si nada se mantiene y luego reinicia:

   netsh int ip reset
   netsh winsock reset

6. Desmarca IPv6 en el adaptador si el equipo no tiene IPv6 funcional y vuelve a probar.

macOS

1. Vacía la caché: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Lee los resolutores en uso: scutil --dns | grep nameserver
3. Sustitúyelos: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Vuelve a lo que entregue el DHCP: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Comprueba el estado y vacía: resolvectl status y luego sudo resolvectl flush-caches
2. Consulta a un servidor de forma explícita para ver si responde siquiera: dig @1.1.1.1 example.com +short
3. Cambia el resolutor en la conexión en lugar de editar /etc/resolv.conf, que normalmente se genera solo:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
   nmcli con up "Wired connection 1"

4. Reinicia el resolutor local si se ha quedado bloqueado: sudo systemctl restart systemd-resolved

Router

1. Apágalo y enciéndelo, y espera a que vuelva el enlace WAN antes de probar.
2. En la página de administración, pon los servidores DNS de la WAN en un par público en lugar de "obtener automáticamente" si el sospechoso es el resolutor del proveedor.
3. Actualiza el firmware. Los fallos del reenviador de DNS son un motivo habitual de que un router necesite reiniciarse cada pocas semanas.
4. Sáltalo como prueba: conecta un teléfono a datos móviles y resuelve el mismo nombre. Si allí funciona, el fallo se reduce a tu red.

Navegador

1. Chrome, Edge y Firefox pueden enviar DNS sobre HTTPS a un proveedor propio, al margen de la configuración de tu sistema. Si el navegador falla mientras dig funciona, desactiva el DNS seguro en los ajustes de privacidad del navegador y vuelve a probar.
2. Vacía la caché interna de Chrome en chrome://net-internals/#dns.

Cuando la consulta es lenta y no está rota

No toda queja sobre el DNS es un fallo. Si las páginas acaban cargando pero se quedan uno o dos segundos paradas antes de que ocurra nada, el resolutor está respondiendo, solo que tarde, y lo de arriba no cambiará gran cosa. Mídelo antes de suponer:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"

Cualquier cifra de una o dos cifras bajas de milisegundos desde una caché caliente es normal. Varios cientos de milisegundos, o un número que varía mucho entre ejecuciones, significa que el resolutor está lejos, sobrecargado, o agotando el tiempo con su primer servidor y recurriendo a un segundo. Ese es otro diagnóstico con otras soluciones, explicado en cómo arreglar una consulta DNS lenta.

Verifícalo desde fuera

Todo lo anterior da por hecho que el fallo está cerca de ti, que es lo habitual. Confírmalo antes de dedicarle una tarde. Pregunta a un resolutor que no tenga nada que ver con tu red si el nombre se resuelve:

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

Que esos respondan mientras tu propio resolutor sigue en silencio demuestra que el dominio está bien y que el problema es tuyo. El silencio de todos ellos desplaza la atención a los servidores de nombres del propio dominio, que pueden estar caídos o ser inalcanzables desde parte de internet.

La accesibilidad de un servidor de nombres no es global. Ejecuta la verificación de consulta DNS para enviar la misma consulta desde puntos de verificación en distintos países y comparar las respuestas una al lado de otra. Cuando unas ubicaciones obtienen resultado y otras agotan el tiempo, estás ante un problema de enrutamiento o de proveedor que afecta a una región, no ante un registro roto, y eso no lo vas a ver por mucho que vacíes cachés en tu portátil.

Cuando tu propio servidor de nombres se queda callado

Un servidor de nombres que se queda callado tumba un sitio tan completamente como un servidor web muerto, y lo hace sin generar una sola línea en tu registro de accesos. Nadie te avisa, porque nadie puede llegar hasta ti. HostTracker ejecuta verificaciones programadas desde más de 300 puntos de verificación en 158 ciudades con 13 tipos de monitor, así que un nombre que deja de resolverse en una región lo detectan los puntos de verificación de allí y no el correo de un cliente. El resto de esta sección está en el grupo de soluciones, y si la pregunta es si un cambio de DNS reciente ya ha llegado a todo el mundo, eso es cómo comprobar la propagación DNS.