DNS explicado: cómo los nombres encuentran las webs y por qué fallan las consultas

¿Qué ocurre cuando introduce una dirección web?

Imagine que escribe www.example.com en el navegador. El navegador y el sistema operativo comprueban primero si ya disponen de una respuesta utilizable. Si hace falta otra consulta, el equipo pregunta al resolvedor recursivo configurado. Este puede responder desde su caché o recorrer la jerarquía DNS hasta localizar el servidor autoritativo responsable del nombre. La respuesta puede incluir una dirección o un alias que requiera otra consulta. Después, el equipo usa la información obtenida para intentar conectarse a la web.

Esta diferencia es importante al diagnosticar un fallo. Una respuesta DNS correcta puede conducir a un servidor caído, una conexión bloqueada o un error de certificado. A la inversa, tener wifi y poder acceder al router no demuestra que la resolución de nombres funcione. Las webs actuales pueden usar varias direcciones y redes de distribución de contenido. Por eso, dos respuestas legítimas pueden ser distintas. Comparar una sola dirección con una captura antigua no basta para decidir que una respuesta es incorrecta.

Resolvedor, DNS autoritativo, registrador y alojamiento tienen funciones distintas

El resolvedor recursivo es el servicio al que suele consultar su equipo. A menudo lo proporciona el operador de internet a través del router, aunque el navegador, una VPN o un ajuste del dispositivo pueden elegir otro. El servicio DNS autoritativo mantiene los registros publicados del dominio. El registrador gestiona el registro del dominio y la delegación en sus servidores de nombres. El alojamiento ejecuta la web. Estas funciones pueden estar en manos de un solo proveedor o de varias organizaciones independientes.

La pregunta útil es qué parte puede administrar usted. Una persona puede revisar el DNS de su propio equipo o router, pero no reparar los registros autoritativos de otra organización. El administrador del dominio puede modificar registros; cambiar el router de un visitante no sustituye un registro ausente. Una red de trabajo gestionada puede necesitar expresamente un resolvedor interno para nombres privados. Sustituirlo sin autorización puede interrumpir recursos de la empresa aunque las webs públicas parezcan funcionar.

¿Qué registros DNS afectan a la web y al correo?

Los registros A asocian un nombre con direcciones IPv4; los AAAA lo asocian con direcciones IPv6. Un CNAME apunta a otro nombre en lugar de hacerlo directamente a una dirección. Los MX identifican los destinos del correo y sus valores de preferencia. Los TXT contienen texto utilizado, por ejemplo, para verificar dominios y autenticar correo. Los NS identifican servidores de nombres autoritativos. Cada registro realiza una tarea diferente. Copiar solo la dirección de la web durante una migración puede dejar el correo o las verificaciones sin funcionar.

Use exactamente el tipo de registro, nombre y valor que indique el servicio responsable. La raíz del dominio y www pueden necesitar registros separados. La autenticación del correo también requiere nombres y sintaxis concretos; un registro adicional o contradictorio puede causar problemas. No considere que todos los TXT son texto prescindible. Antes de cambiar algo, guarde una exportación fechada o capturas de la zona existente y proteja las credenciales. Si no administra el dominio, comunique la observación al propietario en lugar de adivinar un valor nuevo.

• A / AAAA: direcciones asociadas a un nombre de equipo.
• CNAME: alias de otro nombre DNS.
• MX: servidores de correo designados para el dominio.
• TXT: texto publicado, incluida verificación de servicios y políticas de correo.
• NS: servidores autoritativos delegados para un dominio.

¿Por qué un cambio DNS aparece antes en un equipo que en otro?

Las respuestas DNS tienen un tiempo de vida, normalmente denominado TTL. Una caché puede reutilizar la respuesta mientras siga vigente. Un resolvedor que obtuvo el registro antiguo justo antes del cambio puede continuar entregándolo. Otro que no lo tenga guardado obtiene ya el registro nuevo. Dispositivos, navegadores y resolvedores pueden tener sus propias cachés. También se pueden almacenar consultas fallidas. Por eso, la indicación imprecisa de “esperar a la propagación” resulta menos útil que comprobar la delegación, los registros reales y los tiempos de caché aplicables.

Reducir el TTL inmediatamente antes de cambiar un registro no acorta retroactivamente las copias que ya se guardaron con el TTL anterior. Planifique con antelación si controla el dominio. Vaciar la caché de un portátil solo afecta a su caché local, no a todos los resolvedores públicos. Modificar repetidamente el registro mientras espera dificulta el diagnóstico y puede prolongar respuestas diferentes. Confirme primero que los servidores autoritativos publican los valores previstos, documente los anteriores y los nuevos, y deje que caduquen las copias todavía válidas.

Lea el error antes de cambiar la configuración

Una respuesta de nombre inexistente, a menudo representada como NXDOMAIN, indica que el nombre consultado se notificó como inexistente. Compruebe la escritura, el subdominio exacto y la presencia del registro. Un tiempo de espera agotado significa que no llegó una respuesta utilizable dentro del plazo previsto; pueden intervenir el resolvedor, la ruta de red o los filtros. SERVFAIL indica que el resolvedor no pudo completar la petición. Una delegación incorrecta, problemas de validación DNSSEC y fallos anteriores son algunas posibilidades. El mensaje simplificado del navegador no determina por sí solo la causa.

Delimite el alcance del problema. Si falla una web pero funcionan otras y el correo, investigue ese nombre y servicio. Si fallan todos los nombres en un solo equipo, compare otro equipo conectado a la misma red. Si falla toda la red, revise router y conexión del operador antes de atribuirlo a DNS. Un error HTTP, de inicio de sesión o de certificado después de una resolución correcta pertenece a una fase posterior. No ignore un aviso de certificado solo porque una herramienta haya obtenido una dirección.

• Anote nombre exacto, hora, error y si había una VPN conectada.
• Compare el mismo nombre en otro equipo y, si es posible, con otra conexión de confianza.
• Registre el resolvedor configurado y cualquier ajuste de DNS seguro del navegador.
• Consulte el tipo de registro pertinente; un ping a la web no basta.
• Traslade los problemas de registros o delegación al administrador autorizado del dominio.

Una secuencia segura de comprobaciones para casa o una oficina pequeña

Empiece por una observación que no cambie nada: compruebe que la conexión de red esté activa, qué resolvedor está configurado y si se resuelven varios nombres independientes. En Windows, nslookup permite consultar un nombre mediante el resolvedor configurado o un servidor especificado. Otras plataformas ofrecen herramientas equivalentes. Guarde el resultado, incluido el servidor y el tipo de registro. No obtener un A no demuestra que el nombre no exista si solo dispone de un AAAA. La salida de la herramienta debe interpretarse según el servicio.

Compare después el equipo afectado con uno que funcione. El DNS seguro del navegador o una VPN de trabajo pueden utilizar un camino distinto del empleado por la herramienta del sistema. Pruebe un cambio autorizado cada vez y conserve la posibilidad de restaurar el ajuste anterior. Una comparación temporal con otro resolvedor puede ayudar a localizar un fallo en una red personal, pero no es una reparación universal. Redes gestionadas, controles parentales y dominios privados pueden necesitar el resolvedor original. Restaurar valores de fábrica rara vez es un primer paso diagnóstico adecuado.

• Conserve la configuración DNS original antes de un cambio autorizado.
• Utilice una herramienta legítima conocida, no una descarga aleatoria que prometa “reparar DNS”.
• Tras corregir el fallo, vuelva a probar el nombre original, el correo y los servicios internos.
• Retire ajustes temporales innecesarios y documente la configuración definitiva.

DNS cifrado, DNSSEC y seguridad de la web responden a preguntas diferentes

DNS over HTTPS y DNS over TLS pueden cifrar la conexión entre el cliente y su resolvedor. No hacen anónima a la persona, no ocultan toda la información de conexión ni certifican el destino. El resolvedor elegido sigue participando en la consulta. Los ajustes del navegador pueden diferir de los del dispositivo; esto explica que un nombre funcione en una aplicación y falle en otra. Elija un resolvedor con una política comprensible y no eluda sin autorización las normas de una red de trabajo o de un centro educativo.

DNSSEC permite a los resolvedores validadores comprobar datos DNS firmados y su cadena de confianza. No es cifrado ni revisa la web en busca de fraude o software malicioso. Un registro DS antiguo después de migrar el DNS autoritativo puede hacer que una dirección correcta resulte inaccesible para los resolvedores que validan. El administrador debe seguir el procedimiento de migración documentado por su proveedor en lugar de desactivar DNSSEC al azar. Siga utilizando HTTPS, examine solicitudes de acceso inesperadas y separe la seguridad de las cuentas del diagnóstico DNS.

Cambiar alojamiento sin perder acceso a la web o al correo

Una migración de dominio necesita un inventario antes de una modificación. Identifique qué proveedor gestiona registro, DNS, alojamiento y correo. Documente los servidores autoritativos y todos los registros de servicios que deban conservarse. Confirme que la zona nueva contiene los registros necesarios antes de cambiar la delegación. Revise las instrucciones DNSSEC del proveedor, incluida la gestión de DS en el registrador. Programe el cambio con un plan de vuelta atrás y una persona autorizada para modificar el dominio.

Después, verifique respuestas autoritativas, web pública, correo entrante y saliente y servicios dependientes de verificaciones. Mantenga disponible el servicio anterior durante la transición prevista cuando sea viable. No suponga que mover la web traslada los buzones ni que cambiar servidores de nombres copia la zona antigua. Si es visitante y no propietario, comunique el nombre exacto que falla y la hora. Cambiar su DNS no puede crear un registro que el dominio nunca ha publicado.

Ejemplo: la web nueva funciona, pero deja de llegar correo

Imagine una oficina pequeña que mueve su web a otra plataforma. El administrador cambia los servidores de nombres y ve la nueva portada. Después deja de llegar correo. La zona DNS del nuevo proveedor contiene la dirección web, pero no los MX anteriores ni los registros necesarios para autenticar el correo. Es un supuesto explicativo, no un resultado atribuido a un cliente. La web y el correo comparten dominio, pero dependen de registros diferentes.

La respuesta adecuada es comparar la zona antigua guardada con la nueva, obtener los registros exactos del proveedor de correo activo y restaurarlos mediante el administrador autorizado. Compruebe las respuestas autoritativas reales antes de pedir a todos que borren cachés. Confirme que los buzones siguen activos. Pruebe la entrega en ambas direcciones y permita que caduquen las copias antiguas todavía válidas. Para prevenirlo, inventaríe cada servicio, conserve sus registros y verifique la zona completa antes del cambio de servidores.