Si el navegador muestra ERR_NAME_NOT_RESOLVED, admite honestamente que no pudo convertir el nombre del sitio en una dirección IP. Hay Internet, las pestañas giran, pero la página deseada no se abre. Esto no trata del servidor que lo “rechazó” ni de una red lenta. Se trata del DNS, esa misma “agenda telefónica” de Internet, donde cada nombre de dominio debe tener un número. Sin número, no hay conexión.
Normalmente en estos casos actualizamos la página nerviosamente y culpamos al proveedor. Pero el problema a menudo es mucho más banal. Un error tipográfico en la barra de direcciones, un espacio extra, un carácter extraño en lugar de una letra normal, una entrada local en el archivo hosts, un enrutador caprichoso con caché obsoleto. A veces el dominio mismo tiene la culpa: expiró o desaparecieron sus registros. También puede haber filtrado de tráfico por parte del proveedor.
Es importante entender la diferencia entre errores comunes. ERR_CONNECTION_REFUSED significa que se alcanzó el servidor, pero este no responde en el puerto requerido. ERR_CONNECTION_TIMED_OUT insinúa retraso en la red. ERR_NAME_NOT_RESOLVED indica precisamente una falla en la etapa de “encontrar la IP por el nombre”.
La buena noticia es que este es uno de esos problemas que a menudo se resuelven en un par de minutos. Más abajo analizamos por qué ocurre y cómo actuar para devolver Internet a la vida sin recurrir a soluciones mágicas.
Qué significa el error y dónde ocurre
El DNS funciona como una cadena de pasos. Primero el navegador pregunta al sistema si conoce la IP del dominio. El sistema consulta su propia caché y el archivo hosts, luego se dirige al resolvedor del proveedor o a un servidor público. Si hay suerte, la respuesta ya está en la caché. Si no, el resolvedor recorre la jerarquía de servidores de dominios y recopila una respuesta actual. En cualquier etapa puede ocurrir un bloqueo.
La mayoría de las veces ve ERR_NAME_NOT_RESOLVED cuando el resolvedor local no pudo obtener una respuesta o recibió NXDOMAIN. Esto es la anotación formal de “el nombre no existe”. Ocurre si el dominio acaba de registrarse y los registros aún no se han propagado, si el administrador eliminó los registros A o AAAA, o si se indicaron servidores NS incorrectos.
A veces el problema está de su lado. El enrutador almacena en caché una respuesta antigua y no se actualiza, el sistema acumula registros obsoletos, el navegador mantiene su propia caché. También interfieren las VPN, los bloqueadores de publicidad, los filtros corporativos y el control parental a nivel de proveedor. Cualquiera de estas capas puede interceptar la consulta y devolver “vacío”.
También hay un factor humano. La dirección introducida con error puede parecer mucho a la real con solo una letra sustituida por un símbolo similar. En disposiciones de teclado diferentes hay muchos dobles, y los dominios IDN pueden tener homónimos. En esos casos el navegador suele mostrar punycode, y es un buen motivo para revisar la barra de direcciones.
Por último, el propio sitio puede “romperse” a nivel de DNS. El dominio expiró, los servidores NS se desconectaron, no renovaron el servicio con el registrador o desaparecieron las glue records del registrador para servidores NS propios. Desde fuera parece magia, pero en realidad el nombre simplemente no tiene una asignación correcta a una IP.
Diagnóstico rápido sin pánico
Empezamos por lo obvio. Copie la dirección desde el marcador a una barra limpia, elimine espacios y barras innecesarias, pruebe abrir el sitio a través del buscador. Si en los resultados aparece un enlace oficial con descripción, haga clic en ese enlace en lugar de la vieja entrada. Ir desde la página de búsqueda a veces evita caracteres invisibles en la dirección.
Compruebe si el error ocurre en otro dispositivo y en otra red. Active datos móviles e intente desde allí. Si en la red móvil todo funciona, el problema está en el resolvedor o en el enrutador doméstico. Si no se abre en ningún lado, probablemente el problema sea del dominio o de filtrado global.
Revise el archivo hosts. En Windows la ruta es: C:WindowsSystem32driversetchosts. En macOS y Linux la ruta es: /etc/hosts. No debería haber líneas que sustituyan la IP para el dominio en cuestión. Los comentarios comienzan con #, no es necesario tocarlos. Si ve líneas extrañas, coméntelas temporalmente.
Restablezca la caché DNS local y reinicie la pila de red. En Windows ayudan estas órdenes en la terminal con privilegios de administrador:
ipconfig /flushdns
ipconfig /registerdns
netsh winsock reset
netsh int ip reset
En macOS ejecute en el Terminal:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
En Linux verifique el resolvedor en uso. Para systemd sirven los comandos:
resolvectl flush-caches
resolvectl status
Verifique la respuesta DNS. En todas las plataformas valen nslookup y dig. Por ejemplo:
nslookup example.com 1.1.1.1
dig +short A example.com @8.8.8.8
Si los resolvedores públicos devuelven IP y su red sigue con error, el problema es el DNS local. Si nadie devuelve IP, el problema está en el dominio. En el primer caso cambie el DNS y limpie cachés. En el segundo, espere a que el propietario del sitio corrija o contáctelo.
Reparación práctica
La forma más rápida de sortear un resolvedor caprichoso es cambiar temporalmente el DNS a servidores públicos. A continuación hay una lista de proveedores populares y sus direcciones. Son servicios oficiales, útiles tanto para pruebas como para uso permanente. Si al cambiar el DNS el sitio vuelve, ha encontrado el cuello de botella.
| Proveedor | Direcciones IPv4 | Direcciones IPv6 | Página oficial |
|---|---|---|---|
| Google Public DNS | 8.8.8.8, 8.8.4.4 | 2001:4860:4860::8888, 2001:4860:4860::8844 | developers.google.com |
| Cloudflare | 1.1.1.1, 1.0.0.1 | 2606:4700:4700::1111, 2606:4700:4700::1001 | 1.1.1.1 |
| Quad9 | 9.9.9.9, 149.112.112.112 | 2620:fe::fe, 2620:fe::9 | quad9.net |
| OpenDNS Cisco | 208.67.222.222, 208.67.220.220 | 2620:0:ccc::2, 2620:0:ccd::2 | opendns.com |
Cómo cambiar el DNS en los dispositivos. En Windows vaya a la configuración del adaptador de red, abra las propiedades del protocolo IPv4, escriba las direcciones de la tabla y, si lo desea, replique para IPv6. Tras guardar, limpie la caché y reinicie el navegador. En macOS abra Red, seleccione la interfaz activa, pulse Avanzado, pestaña DNS, añada las nuevas direcciones, aplique y reconecte la red.
En Android puede activar DNS privado e indicar el nombre del proveedor con soporte DoT. Para Cloudflare es 1dot1dot1dot1.cloudflare-dns.com, para Google es dns.google. En la configuración de Wi‑Fi también se pueden introducir direcciones IPv4 manualmente para una red concreta. En iOS el DNS se cambia en la configuración de la red Wi‑Fi específica, en el campo DNS manual. Si usa un perfil VPN, compruebe que no esté sustituyendo el resolvedor.
Buena práctica es actualizar el firmware del enrutador y configurar en él un DNS público en la sección Internet o WAN. Así se corrige para todos los dispositivos domésticos. Tras el cambio reinicie el enrutador para vaciar la caché. Si el enrutador tiene filtros familiares o categoría de “sitios para adultos”, a veces generan falsos positivos. Para diagnosticar, conviene desactivarlos temporalmente.
No olvide el archivo hosts. Si antes asignó un dominio a una IP concreta y el sitio cambió de dirección, el navegador seguirá usando la antigua. Elimine o comente esa línea. Esto es muy común entre desarrolladores tras pruebas en servidores locales.
A veces ayuda desactivar “DNS seguro” en el propio navegador o, al contrario, activarlo. En Chrome es la opción “Usar DNS seguro”, donde se puede elegir proveedor. Para un experimento limpio conviene sincronizar la opción con la configuración del sistema, para no multiplicar efectos inesperados.
Causas raras y cómo reconocerlas
El problema puede estar en la zona de dominio. Si el dominio tiene DNSSEC activado y las firmas expiraron, algunos resolvedores se negarán a responder. Los síntomas parecen un fallo común, pero los resolvedores públicos más exigentes devolverán vacío. Aquí el usuario poco puede hacer; queda esperar a que el propietario del dominio corrija las firmas.
La desincronización de servidores NS en el registrador provoca fallos de resolución. Cuando los NS están indicados pero no delegados correctamente, parte del mundo ve el dominio y parte no. Se detecta comparando respuestas desde distintas regiones. Los comandos dig NS y dig @8.8.8.8 frente a @1.1.1.1 muestran la situación. Normalmente lo arregla el registrador.
También hay retrasos en la propagación de registros. Un administrador cambió la entrada A, pero el TTL era alto, así que las respuestas antiguas permanecieron en caché de los proveedores. En una red todo ya se abre, en otra no. La solución es simple: esperar el TTL o usar otro resolvedor temporalmente.
Las redes corporativas suelen emplear split‑DNS. Dentro de la empresa el dominio tiene una IP y fuera otra. Conectarse por VPN envía consultas a servidores internos; desconectarse vuelve a los externos. Si al cambiar algo falla, el navegador ve el error. Reconectar la VPN y vaciar cachés suele restaurar la normalidad.
Y finalmente, el factor humano. La dirección puede parecer la original pero con sustitución de caracteres. Si ve en la barra una entrada extraña que empieza por xn--, es la representación punycode de un dominio con caracteres nacionales. Conviene volver a la página principal desde el buscador y confirmar que está en el sitio oficial, no en una copia de phishing. La suplantación a menudo se disfraza con ERR_NAME_NOT_RESOLVED para que usted siga otro enlace.
Prevención y lista de comprobación corta
Mantenga el DNS bajo control. En el enrutador doméstico elija un proveedor confiable, actualice el firmware y limpie la caché reiniciando. En dispositivos no mezcle el DNS seguro del sistema y el del navegador, porque diagnosticar problemas se vuelve una lotería. Si trabaja con sitios y dominios, mantenga los registros actualizados y vigile las fechas de renovación.
Guarde herramientas útiles a mano. Comandos nslookup y dig, verificación del hosts, restablecimiento de caché del sistema y cambio temporal de resolvedor a uno público. Este conjunto resuelve aproximadamente el 80 por ciento de los casos. No abuse de diez extensiones de bloqueo de publicidad ni de VPN experimentales: también suelen romper la resolución de nombres.
Para padres y administradores corporativos un recordatorio. Los filtros de contenido pueden bloquear dominios legítimos junto con los dudosos. Si un usuario se queja de ERR_NAME_NOT_RESOLVED y tiene categorización activada, revise los registros. A veces basta añadir el dominio a la lista blanca para que todo funcione.
Y por último. Si un sitio importante deja de ser accesible en todas partes, escriba a los propietarios a través de redes sociales o correo desde el perfil público. El administrador puede no percatarse del problema hasta que los usuarios lo reporten. Un mensaje con captura del error y un par de salidas de dig acelera mucho la reparación.
Resumen para los prácticos. Verifique la dirección por si hay errores, intente abrir desde otra red, limpie cachés, revise hosts, cambie a DNS público y pruebe con nslookup. Si nada funciona, probablemente el dominio esté roto por parte del propietario. En ese caso queda esperar o avisar del fallo. No hay que asustarse: es un problema comprensible y solucionable.
- Google Public DNS y Cloudflare son útiles para una comprobación rápida
- El archivo hosts suele ser una causa oculta
- VPN, filtros y bloqueadores de publicidad afectan la resolución de nombres
- El TTL de registros DNS provoca retrasos en la propagación de cambios
