Ingeniería
Registros DNS explicados: cuáles importan y cuáles rompen su web
A, AAAA, MX, NS, TXT, CAA y SOA: función de cada uno, errores críticos que dejan webs inactivas y la técnica de TTL para migraciones sin incidencias.
La mayoría de las caídas de servicio que se notifican como «la página web no funciona» son en realidad fallos de DNS. El servidor opera correctamente, los archivos del sitio están intactos, pero un registro de texto apunta al destino erróneo o los servidores intermediarios conservan en caché una dirección obsoleta.
El DNS es también la capa menos visible de la infraestructura web. Rara vez se supervisa hasta que algo se rompe, y para entonces el cambio que provocó el fallo suele haberse realizado semanas atrás por alguien que ya no forma parte del equipo.
A continuación, detallamos la función de cada tipo de registro y sus errores más habituales.
A y AAAA: dónde reside el sitio web
El registro A asigna un nombre de host a una dirección IPv4. El registro AAAA lo asigna a una dirección IPv6.
example.com. A 203.0.113.10
example.com. AAAA 2001:db8::1
www.example.com. A 203.0.113.10Si estos registros están mal configurados o ausentes, ningún otro elemento de esta guía tendrá efecto.
El error típico: publicar un registro A para example.com pero no para www.example.com, o viceversa. La mitad de los visitantes escribirán la URL con la variante contraria y encontrarán un error de conexión. Usted no lo percibirá si siempre accede utilizando la misma dirección en su navegador.
Sobre IPv6: en múltiples mercados, una parte sustancial del tráfico móvil opera exclusivamente bajo IPv6 y accede a servidores solo-IPv4 mediante pasarelas de traducción de operador (CGNAT), lo que añade latencia innecesaria a cada petición. Si su proveedor de alojamiento soporta IPv6, configurar registros AAAA no supone coste alguno y elimina saltos intermedios de red.
MX: dónde se recibe el correo electrónico
example.com. MX 10 mx1.provider.com.
example.com. MX 20 mx2.provider.com.Define los servidores que aceptan correo entrante para su dominio. El número de prioridad más bajo tiene preferencia; los números más altos actúan como servidores de respaldo (fallback).
Dos confusiones frecuentes:
Los registros MX gestionan únicamente el correo entrante. Si sus correos salientes terminan en la carpeta de spam de sus clientes, el registro MX no es el causante: el problema reside en SPF, DKIM y DMARC, que se configuran mediante registros TXT.
Un registro MX debe apuntar siempre a un nombre de host, jamás a una dirección IP directa. Una entrada como MX 10 203.0.113.5 es inválida según el estándar y muchos servidores de correo rechazarán los mensajes dirigidos a un dominio configurado de esa forma.
NS: qué servidores tienen la autoridad
example.com. NS ns1.provider.com.
example.com. NS ns2.provider.com.Los servidores de nombres autoritativos que responden por su dominio. Deben coincidir exactamente con los configurados en su agente registrador (registrar). Los registros NS definidos dentro de la zona DNS y la delegación en el registrador son dos configuraciones distintas que pueden entrar en discrepancia.
El error clásico en migraciones: traslada el hosting, actualiza los registros DNS en el nuevo proveedor y la web funciona en su ordenador pero falla para terceros. La causa casi siempre es que la delegación en el registrador sigue apuntando a los servidores de nombres antiguos, por lo que medio internet continúa consultando al proveedor anterior.
Mantenga siempre al menos dos servidores de nombres. Disponer de uno solo constituye un punto único de fallo para todo su dominio, incluido el correo electrónico.
TXT: el contenedor multipropósito
Registros de texto libre utilizados para una lista creciente de validaciones y protocolos de seguridad:
- SPF — define qué servidores están autorizados a enviar correo en nombre de su dominio:
v=spf1 include:_spf.google.com ~all - DMARC — política de autenticación y reporte de correo, configurada en
_dmarc.example.com - DKIM — clave pública de firma criptográfica, en
selector._domainkey.example.com - Verificación de dominio — Google Search Console, Microsoft 365, Atlassian, herramientas analíticas y servicios corporativos.
Dos reglas fundamentales que suelen infringirse:
Solo debe existir un registro SPF por dominio. Tener dos registros TXT que comiencen por v=spf1 constituye un error de sintaxis que invalida ambos. Suele ocurrir cuando se contrata una nueva herramienta de marketing y se añade un registro nuevo en lugar de editar e integrar el existente. Unifíquelos siempre en una única línea.
Los registros TXT se acumulan. La mayoría de dominios veteranos conservan registros de verificación de herramientas dadas de baja años atrás. Aunque inofensivos, generan ruido que dificulta auditorías y facilita errores en SPF. Realice una limpieza anual.
CAA: quién puede emitir certificados SSL para su dominio
El tipo de registro más infrautilizado de esta lista.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"El registro CAA declara qué autoridades de certificación (CA) tienen autorización expresa para emitir certificados SSL/TLS para su dominio. Sin este registro, cualquier entidad emisora pública puede generar un certificado. Con él, solo las entidades expresamente autorizadas por usted.
Las autoridades emisoras están obligadas a verificar este registro antes de emitir un certificado. Es un control de seguridad eficaz contra emisiones fraudulentas, se configura en dos minutos y casi ninguna empresa lo implementa.
Dos aspectos clave: incluya todas las entidades emisoras que utilice realmente (incluyendo los certificados automáticos de su CDN o hosting) y use issuewild ";" para prohibir certificados comodín si no los requiere.
SOA: metadatos de la zona DNS
Existe uno por zona y suele gestionarse de forma automática. El campo que conviene conocer es el número de serie (serial number): se incrementa cada vez que se modifica la zona. Durante una migración, si el número de serie no ha cambiado, su modificación no se ha publicado. Verificar este valor resuelve muchas dudas de sincronización.
TTL: el parámetro que complica las migraciones
Cada registro incluye un Time To Live (TTL): la cantidad de segundos durante los cuales los servidores resolutores intermedios pueden almacenar la respuesta en caché.
Un registro con un TTL de 24 horas (86400 segundos) puede tardar un día completo en propagarse globalmente. No existe mecanismo técnico para acelerar este proceso a posteriori: una vez que un servidor almacena la respuesta antigua, continuará entregándola hasta que expire el tiempo definido.
El protocolo técnico para evitar incidencias en migraciones:
- 48 horas antes de la migración, reduzca el TTL de los registros que va a modificar a 300 segundos.
- Espere a que el TTL antiguo expire completamente en la red global para que todos los resolutores adopten el valor corto.
- Ejecute el cambio de servidor. La propagación tardará únicamente cinco minutos.
- 24 horas después, incremente el TTL nuevamente a 3600 segundos o más.
El paso 4 es necesario: mantener un TTL permanentemente bajo incrementa el volumen de consultas DNS y ralentiza ligeramente las conexiones iniciales de los usuarios.
Por qué distintas herramientas muestran resultados diferentes
Porque consultan a resolutores DNS diferentes, y cada uno almacena copias en caché según el momento en que realizó su última petición.
Tras un cambio reciente, esta discrepancia es normal y se estabiliza al expirar los TTL. Si persiste más allá del periodo de TTL, significa que existen respuestas contradictorias activas, generalmente porque siguen coexistiendo dos servidores de nombres tras una migración incompleta.
Puede inspeccionar todos los registros de un dominio y sus TTL con nuestra herramienta gratuita de consulta DNS. Las consultas se ejecutan directamente desde su navegador, reflejando con exactitud lo que resuelve su red local.
Lista de verificación para migraciones
- Exporte una copia completa de la zona DNS actual antes de realizar cualquier cambio.
- Reduzca los TTL a 300 segundos con 48 horas de antelación.
- Configure la zona completa en el nuevo proveedor antes de modificar la delegación en el registrador.
- Actualice los servidores de nombres (NS) en el panel de su registrador de dominio.
- Verifique que los registros A, AAAA, MX, TXT y CAA resuelven correctamente en el nuevo destino.
- Realice pruebas de envío y recepción de correo electrónico.
- Mantenga activa la zona en el proveedor anterior durante al menos una semana: resolutores con registros NS en caché prolongada seguirán consultándolo temporalmente.
- Restablezca los TTL a valores estándar una vez estabilizado el tráfico.
