Servidor DNS No Responde: Guía Completa de Solución de Problemas

Un error de "DNS server not responding" significa que su sistema operativo envió una consulta de resolución a un resolver DNS y no recibió respuesta dentro del tiempo de espera, por lo que el navegador nunca obtuvo la dirección IP necesaria para abrir una conexión TCP. El resultado es una página que no carga aunque el enlace de red físico esté completamente operativo. La causa raíz puede estar en cualquier punto de la cadena de resolución: su stub resolver local, el resolver recursivo de su ISP, un servidor autoritativo upstream, o un dispositivo de red mal configurado entre usted y cualquiera de ellos.

Esta guía recorre cada capa de esa cadena — desde un reinicio del router de 30 segundos hasta la sustitución de controladores a bajo nivel — con comandos exactos para Windows, macOS y Linux, además de una comparación de resolvers públicos y una matriz de decisión para ayudarle a aislar el fallo rápidamente.

Qué ocurre realmente durante la resolución DNS

Antes de solucionar el error, entender la ruta de resolución evita esfuerzos innecesarios. Cuando escribe example.com en un navegador:

1. El sistema operativo comprueba su caché DNS local (y el archivo hosts).
2. Si no existe ningún registro en caché, el stub resolver reenvía la consulta al resolver recursivo configurado en la interfaz de red (normalmente su router o un servidor asignado por el ISP).
3. El resolver recursivo recorre la jerarquía DNS — servidores raíz, servidores de nombres TLD, servidores de nombres autoritativos — y devuelve el registro A o AAAA final.
4. El sistema operativo almacena el resultado en caché durante el TTL del registro y pasa la IP al navegador.

Un error de "not responding" normalmente se produce en el paso 2 o 3. El stub resolver envió un paquete UDP al puerto 53 y obtuvo silencio. Ese silencio tiene un número sorprendentemente grande de causas.

Causas raíz del error DNS server not responding

Fallos del lado del resolver DNS

• El resolver recursivo configurado está temporalmente sobrecargado o fuera de línea.
• La infraestructura DNS de su ISP está bajo un ataque DDoS o en mantenimiento.
• La dirección IP del resolver ha cambiado pero su dispositivo aún conserva el valor antiguo.

Problemas de red local y hardware

• Errores en el firmware del router que corrompen el relay DNS (común en dispositivos de consumo tras largos períodos de actividad).
• Una concesión DHCP que proporcionó una dirección de servidor DNS obsoleta o no válida.
• Un cable Ethernet defectuoso o una señal Wi-Fi degradada que causa pérdida de paquetes específicamente en el puerto UDP 53.

Configuraciones incorrectas a nivel de host

• Una caché DNS local corrupta o envenenada que contiene respuestas negativas obsoletas.
• Una dirección DNS introducida manualmente que es incorrecta o ya no es accesible.
• Una entrada en el archivo hosts que entra en conflicto con la respuesta DNS esperada.

Interferencia del software de seguridad

• Firewalls o herramientas de seguridad de endpoint que bloquean el puerto UDP/TCP 53 saliente o interceptan consultas DNS para inspeccionarlas y luego las descartan.
• Clientes VPN que redirigen el tráfico DNS a través de un endpoint de túnel que actualmente no es accesible.
• Software de control parental que actúa como proxy DNS local y falla silenciosamente.

Problemas de controladores y del sistema operativo

• Un controlador NIC desactualizado o corrupto que gestiona incorrectamente los datagramas UDP.
• El servicio DNS Client de Windows (Dnscache) en estado bloqueado.
• Un proceso mDNSResponder de macOS que ha consumido memoria excesiva y ha dejado de responder.

Soluciones paso a paso: ordenadas por esfuerzo y probabilidad

Siga estos pasos en orden. Cada uno lleva menos de cinco minutos y elimina una capa específica del problema.

Paso 1: Verificar primero el alcance del problema

Antes de modificar cualquier configuración, ejecute un diagnóstico rápido para confirmar que DNS es realmente el punto de fallo y no la conectividad general:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Si ping 8.8.8.8 tiene éxito pero nslookup example.com falla, la resolución DNS es definitivamente el problema. Si ping 8.8.8.8 también falla, el problema es más profundo — probablemente enrutamiento o conectividad física — y DNS es un síntoma, no la causa.

Paso 2: Reiniciar el router y el módem

Un ciclo de apagado limpia la caché interna del relay DNS del router, restablece las concesiones DHCP y restablece la conexión WAN con nuevas asignaciones de servidor DNS de su ISP.

1. Desenchufe el cable de alimentación tanto del módem como del router.
2. Espere 30 segundos completos (los condensadores necesitan tiempo para descargarse).
3. Encienda primero el módem; espere a que se sincronice completamente (luz WAN fija).
4. Encienda el router después; espere a que complete su secuencia de arranque.
5. Vuelva a conectar su dispositivo y repita la prueba nslookup del Paso 1.

Caso especial: Si su router lleva semanas funcionando sin reiniciarse, su relay DNS (dnsmasq o similar) puede tener la caché llena o una fuga de memoria. Algunos routers proporcionados por ISP tienen errores conocidos donde el relay DNS deja de reenviar consultas después de un cierto umbral de tiempo de actividad. Un reinicio es la solución más rápida.

Paso 3: Vaciar la caché DNS local

Las entradas de caché obsoletas o corruptas hacen que el sistema operativo devuelva resultados incorrectos o genere fallos de búsqueda antes de que una consulta salga siquiera del equipo.

Windows:

ipconfig /flushdns

Debería ver: Successfully flushed the DNS Resolver Cache.

macOS (específico por versión — use el comando correcto para su sistema operativo):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Paso 4: Cambiar a un resolver DNS público fiable

Si el resolver DNS de su ISP es el problema, cambiar a un resolver público bien mantenido es la solución más rápida. La tabla siguiente compara las opciones más utilizadas:

Cloudflare 1.1.1.1 mide consistentemente la latencia de consulta promedio global más baja en benchmarks independientes. Quad9 es la mejor opción si desea bloqueo pasivo de dominios de malware sin gestionar un filtro DNS separado.

Cambiar DNS en Windows 10/11:

1. Abra Configuración > Red e Internet > Cambiar opciones del adaptador.
2. Haga clic derecho en su adaptador activo y seleccione Propiedades.
3. Seleccione Protocolo de Internet versión 4 (TCP/IPv4) y haga clic en Propiedades.
4. Seleccione Usar las siguientes direcciones de servidor DNS.
5. Introduzca las IPs del resolver primario y secundario elegidos.
6. Haga clic en Aceptar, luego ejecute ipconfig /flushdns para borrar las entradas de caché obsoletas.

Para redes IPv6, repita el proceso para Protocolo de Internet versión 6 (TCP/IPv6) usando las direcciones IPv6 del resolver (p. ej., Cloudflare: 2606:4700:4700::1111 y 2606:4700:4700::1001).

Cambiar DNS en macOS:

1. Abra Configuración del Sistema > Red.
2. Seleccione su conexión activa y haga clic en Detalles.
3. Vaya a la pestaña DNS.
4. Elimine las entradas existentes con el botón – y añada las IPs del resolver elegido con +.
5. Haga clic en Aceptar y Aplicar.

Cambiar DNS en Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
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"

Paso 5: Reiniciar el servicio DNS Client (Windows)

El servicio DNS Client de Windows (Dnscache) almacena en caché los nombres resueltos y gestiona el stub resolver. Si entra en estado bloqueado, todas las consultas DNS fallan silenciosamente.

net stop dnscache
net start dnscache

Alternativamente, a través de la consola de Servicios: presione Win + R, escriba services.msc, localice DNS Client, haga clic derecho y seleccione Reiniciar. Tenga en cuenta que en algunas versiones de Windows 11 la opción de reinicio aparece en gris en la interfaz gráfica — use el método de línea de comandos en su lugar.

Paso 6: Deshabilitar temporalmente el firewall o el software de seguridad

Los firewalls de terceros y las suites de protección de endpoints a veces interceptan el tráfico DNS para inspeccionarlo y, debido a un conflicto de reglas o un error del motor, descartan los paquetes por completo.

Windows Defender Firewall (solo prueba temporal):

netsh advfirewall set allprofiles state off

Vuelva a habilitarlo inmediatamente después de la prueba:

netsh advfirewall set allprofiles state on

macOS:

Navegue a Configuración del Sistema > Privacidad y seguridad > Firewall y desactívelo para realizar pruebas.

Si deshabilitar el firewall resuelve el problema, no lo deje deshabilitado. En su lugar, abra el editor de reglas del firewall y busque reglas que bloqueen el tráfico saliente en el puerto UDP 53 y el puerto TCP 53. Añada reglas de permiso explícitas para las IPs del resolver DNS elegido.

Los clientes VPN merecen especial atención aquí. Muchas aplicaciones VPN instalan un proxy DNS local en 127.0.0.1:53 y redirigen todas las consultas a través del túnel. Si el servidor VPN no es accesible, todas las consultas DNS fallan. Desconecte la VPN, pruebe DNS, luego vuelva a conectar y compruebe la configuración de fuga DNS del cliente VPN.

Paso 7: Probar con un navegador diferente

Ciertas extensiones de navegador — especialmente bloqueadores de anuncios, herramientas de privacidad y plugins de seguridad — interceptan consultas DNS-over-HTTPS (DoH) o modifican el comportamiento del resolver del sistema. Si DNS funciona en un navegador pero no en otro, el problema es a nivel de extensión, no a nivel del sistema operativo.

Pruebe primero en una ventana privada/incógnito (las extensiones suelen estar deshabilitadas). Si eso lo resuelve, deshabilite las extensiones una por una para identificar la culpable. Si el problema persiste en todos los navegadores, el fallo está en la capa del sistema operativo o de red.

Paso 8: Actualizar o revertir los controladores de red

Un controlador NIC corrupto puede causar un manejo errático de paquetes UDP, lo que se manifiesta como fallos DNS intermitentes incluso cuando las conexiones TCP funcionan.

Windows — actualizar mediante el Administrador de dispositivos:

1. Presione Win + X y seleccione Administrador de dispositivos.
2. Expanda Adaptadores de red.
3. Haga clic derecho en su adaptador y seleccione Actualizar controlador > Buscar controladores automáticamente.
4. Reinicie tras la instalación.

Windows — revertir un controlador actualizado recientemente:

Si el error DNS comenzó inmediatamente después de una actualización de Windows, el nuevo controlador puede ser la regresión. En el Administrador de dispositivos, haga clic derecho en el adaptador, seleccione Propiedades > Controlador > Revertir controlador.

macOS: Los controladores NIC están incluidos con macOS. Aplique todas las actualizaciones del sistema pendientes a través de Configuración del Sistema > General > Actualización de software.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Paso 9: Comprobar las conexiones de red físicas

Si está usando una conexión por cable, un cable Ethernet degradado causa pérdida de paquetes intermitente que afecta desproporcionadamente a los protocolos basados en UDP como DNS (que no tiene retransmisión integrada en la capa de aplicación).

• Vuelva a conectar ambos extremos del cable Ethernet.
• Sustituya el cable por uno en buen estado.
• Pruebe un puerto diferente en el router o switch.
• Compruebe los LEDs indicadores de enlace de la NIC — una luz verde o ámbar fija confirma el enlace físico; una luz parpadeante o ausente indica un problema de capa 1.

Paso 10: Ejecutar el solucionador de problemas de red de Windows

Windows incluye un diagnóstico automatizado que puede detectar y corregir configuraciones incorrectas comunes de DNS, incluyendo el restablecimiento del cliente DNS y el vaciado de la caché.

Navegue a Configuración > Sistema > Solucionar problemas > Otros solucionadores de problemas > Conexiones a Internet y ejecute el asistente. Intentará reparaciones automáticas e informará de lo que encontró. Aunque no detecta todos los escenarios, es una comprobación útil que lleva menos de un minuto.

Paso 11: Comprobar y editar el archivo hosts

Un archivo hosts corrupto o modificado maliciosamente puede anular el DNS para dominios específicos, causando fallos de resolución que parecen idénticos a un error de servidor DNS.

Windows — abrir con privilegios elevados:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Busque entradas que redirijan dominios comunes a 0.0.0.0 o 127.0.0.1. El software de seguridad, los bloqueadores de anuncios y el malware modifican este archivo. Elimine las entradas sospechosas, guarde y vacíe la caché DNS.

Paso 12: Restablecer la pila TCP/IP y Winsock (Windows)

Si varios componentes de red están mal configurados, un restablecimiento completo de la pila es más rápido que buscar configuraciones individuales:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Reinicie el equipo después de ejecutar los cinco comandos. Esto restablece los parámetros del registro TCP/IP y el catálogo Winsock a su estado predeterminado sin afectar a los controladores del adaptador de red.

Paso 13: Restablecer el router a los valores de fábrica

Use esto como último recurso antes de llamar a su ISP. Un restablecimiento de fábrica borra toda la configuración personalizada — SSIDs Wi-Fi, contraseñas, reglas de reenvío de puertos y cualquier configuración DNS personalizada — y restaura el router a su estado de fábrica.

La mayoría de los routers tienen un botón de reinicio empotrado. Manténgalo pulsado con un alfiler durante 10–15 segundos hasta que los LEDs de estado parpadeen. Después de que el router se reinicie, reconfigure su red desde cero. Si DNS funciona inmediatamente después del restablecimiento, una configuración incorrecta del router era la causa.

Paso 14: Contactar con su ISP

Si todos los pasos anteriores fallan y el problema afecta a todos los dispositivos de su red, el problema casi con certeza está por encima de su router — ya sea en la infraestructura del resolver recursivo del ISP o en el propio enlace WAN. Contacte con el soporte técnico de su ISP con la siguiente información preparada:

• Resultados de nslookup example.com usando tanto el DNS de su ISP como un resolver público como 8.8.8.8.
• Si el problema es intermitente o constante.
• Si cambiar a un punto de acceso móvil (evitando su ISP por completo) resuelve el problema.

Esa última prueba es la comprobación definitiva de aislamiento del ISP.

Configuración DNS para administradores de servidores

Si gestiona un entorno de VPS Hosting o un Servidor Dedicado, los errores DNS adquieren dimensiones adicionales. Un resolver mal configurado en un servidor afecta a todas las aplicaciones que se ejecutan en él — servidores web, entrega de correo, gestores de paquetes y agentes de monitorización dependen todos de una resolución de nombres fiable.

Verificar la configuración del resolver en servidores Linux:

cat /etc/resolv.conf

Un archivo en buen estado debe contener al menos dos líneas nameserver apuntando a resolvers fiables:

nameserver 1.1.1.1
nameserver 8.8.8.8

En sistemas que usan systemd-resolved, /etc/resolv.conf es un enlace simbólico. Editarlo directamente no tiene efecto. Use resolvectl en su lugar:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Probar la latencia de resolución desde un servidor:

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

Si los tiempos de consulta superan consistentemente los 200ms, el resolver está geográficamente distante o bajo carga. Cambie a un resolver con un punto de presencia más cercano al centro de datos de su servidor.

Para servidores que ejecutan entornos cPanel VPS, la configuración DNS también se gestiona a través de la página Basic cPanel & WHM Setup de WHM. Asegúrese de que los resolvers listados allí coincidan con los de /etc/resolv.conf para evitar problemas de resolución split-brain.

DNS y registro de dominios: la conexión upstream

Un error de "DNS server not responding" en su propio dominio — en lugar del de otra persona — a menudo se debe a la configuración de los servidores de nombres a nivel del registrador. Si registró recientemente un dominio o cambió los servidores de nombres a través de Registro de Dominios, la propagación puede tardar hasta 48 horas. Durante ese período, algunos resolvers en todo el mundo aún conservan los registros NS antiguos.

Use un comprobador de propagación o consulte directamente múltiples resolvers distribuidos geográficamente:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Las discrepancias entre las respuestas de los resolvers durante la propagación son normales. Si las respuestas siguen siendo inconsistentes después de 48 horas, los registros NS en el registrador probablemente están mal configurados.

Seguridad DNS: DNSSEC y DNS-over-HTTPS

Las consultas DNS estándar viajan en texto plano por el puerto UDP 53, lo que las hace vulnerables a ataques de DNS spoofing y envenenamiento de caché. Dos tecnologías complementarias abordan esto:

DNSSEC añade firmas criptográficas a los registros DNS, permitiendo a los resolvers verificar que una respuesta es auténtica y no ha sido manipulada. Protege la integridad de los datos pero no cifra la consulta en sí.

DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) cifran toda la consulta DNS, evitando la escucha y la manipulación en ruta. Los navegadores modernos admiten DoH de forma nativa. Para habilitarlo en todo el sistema en Windows 11, navegue a Configuración > Red e Internet > [su adaptador] > Asignación de servidor DNS > Editar y establezca el cifrado en Solo cifrado (DNS over HTTPS).

Para servidores, configure systemd-resolved para usar DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Si está ejecutando Alojamiento de Correo Electrónico o gestionando su propio servidor de correo, la configuración DNS correcta — específicamente los registros SPF, DKIM y DMARC — es fundamental para la entregabilidad. Los fallos DNS en un servidor de correo no solo interrumpen la navegación saliente; causan correos diferidos o rebotados y fallos en la validación de certificados TLS.

Certificados SSL y dependencia de DNS

La emisión y renovación de certificados TLS dependen completamente de DNS. Las Autoridades de Certificación que realizan la validación de dominio (DV) mediante el desafío ACME DNS-01 deben resolver el registro TXT _acme-challenge de su dominio. Si DNS está roto en el momento de la renovación, las herramientas automatizadas como Certbot fallarán silenciosamente, y sus Certificados SSL expirarán — llevándose HTTPS con ellos.

Configure monitorización tanto para la resolución DNS como para la expiración de certificados. Una comprobación simple basada en cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Matriz de decisión: aislar la capa de fallo DNS

Use esta matriz para identificar la capa de fallo antes de dedicar tiempo a soluciones que no se aplican a su situación.

Lista de verificación técnica de puntos clave

• Ejecute primero ping 8.8.8.8. Si falla, DNS no es su problema principal — solucione primero el enrutamiento o la conectividad física.
• Vacíe siempre la caché DNS local después de cambiar la configuración del resolver; las entradas obsoletas enmascararán si la solución funcionó.
• Cambie a Cloudflare 1.1.1.1 o Quad9 9.9.9.9 como primer cambio de resolver — ambos son más rápidos y fiables que la mayoría de los resolvers de ISP.
• En Windows, si la interfaz gráfica de Servicios muestra en gris la opción de reinicio del DNS Client, use net stop dnscache && net start dnscache desde un símbolo del sistema elevado.
• En servidores Linux, nunca edite /etc/resolv.conf directamente en sistemas systemd-resolved — los cambios se sobrescriben al reiniciar la red. Use resolvectl o nmcli.
• Los clientes VPN son un culpable silencioso frecuente. Pruebe siempre con la VPN desconectada antes de escalar.
• Para sus propios dominios, dig +trace omite todas las cachés y muestra exactamente lo que devuelven los servidores autoritativos — úselo antes de asumir un problema de resolver.
• Habilite la validación DNSSEC y DNS-over-TLS/HTTPS en servidores de producción para eliminar toda una clase de fallos DNS basados en spoofing.
• En servidores, monitorice tanto el estado de la resolución DNS como la expiración de certificados SSL juntos — un fallo DNS hará que la renovación del certificado falle silenciosamente días después.

Preguntas frecuentes

¿Por qué falla DNS aunque tenga una conexión a internet funcionando?

La resolución DNS usa paquetes UDP al puerto 53, que es independiente de las conexiones TCP que usa su navegador para cargar páginas. Una regla de firewall, un relay DNS caído en su router, o un resolver inactivo pueden bloquear específicamente el puerto 53 mientras dejan todo el demás tráfico sin afectar. Ejecute ping 8.8.8.8 para confirmar la conectividad IP, luego nslookup example.com para confirmar que DNS es el fallo aislado.

¿Es seguro usar permanentemente Google o Cloudflare DNS en lugar del resolver de mi ISP?

Sí, para la mayoría de los usuarios y casos de uso. Tanto Google Public DNS como Cloudflare 1.1.1.1 admiten validación DNSSEC y ofrecen SLAs de disponibilidad más altos que los resolvers típicos de ISP. La contrapartida es que sus consultas DNS son procesadas por un proveedor de infraestructura de terceros en lugar de su ISP. Cloudflare publica una estricta política de no registro de consultas; Google conserva registros anonimizados durante hasta 48 horas.

¿Cuál es la diferencia entre vaciar la caché DNS y cambiar el servidor DNS?

Vaciar la caché elimina los resultados de resolución almacenados localmente, obligando al sistema operativo a enviar consultas nuevas al resolver configurado. Cambiar el servidor DNS redirige a dónde se envían esas consultas. Si su caché contiene una entrada envenenada u obsoleta, vaciarla lo soluciona sin cambiar su resolver. Si su resolver está caído o es lento, cambiar la dirección del servidor lo soluciona sin tocar la caché. En la práctica, hacer ambas cosas juntas después de un fallo DNS es el enfoque más limpio.

¿Por qué nslookup tiene éxito pero el navegador sigue mostrando un error DNS?

Los navegadores utilizan cada vez más su propia implementación de DNS-over-HTTPS, que omite completamente el resolver del sistema operativo. Si el endpoint DoH configurado en el navegador no es accesible, puede fallar incluso cuando el resolver del sistema funciona correctamente. Compruebe la configuración de privacidad o seguridad del navegador para encontrar una opción de "DNS seguro" o "DNS over HTTPS" y desactívela o apúntela a un proveedor DoH accesible.

¿Cómo diagnostico problemas DNS en un VPS Linux sin interfaz gráfica?

Use dig, nslookup y resolvectl desde la línea de comandos. Ejecute dig @1.1.1.1 example.com para probar un resolver específico directamente, omitiendo por completo la configuración local. Ejecute resolvectl status para ver qué resolver está usando actualmente el sistema y si DNSSEC está activo. Compruebe /etc/resolv.conf para confirmar los servidores de nombres configurados, y verifique que el archivo no es un enlace simbólico roto con ls -la /etc/resolv.conf.