Entendiendo los registros DNS (A, CNAME, MX, TXT)

Qué hace el DNS y dónde viven los registros

El Sistema de Nombres de Dominio (DNS) traduce nombres fáciles de recordar, como ejemplo.es, en los datos que necesitan los ordenadores: direcciones IP, servidores de correo, políticas de seguridad y mucho más. Sus especificaciones básicas son las RFC 1034 y RFC 1035, publicadas en 1987, y el modelo apenas ha cambiado desde entonces.

El DNS es una base de datos distribuida y jerárquica. En la cima están los servidores raíz; por debajo, los servidores de cada dominio de primer nivel, como .com o .es; y por debajo de estos, los servidores de nombres autoritativos de cada dominio. Al registrar un dominio, su registrador publica en la zona del TLD unos registros NS que apuntan a los servidores que alojan su zona. Esa zona no es más que un conjunto de registros de recursos, y de ellos trata esta guía.

El recorrido de una consulta

1. El navegador pregunta al sistema operativo, que a su vez pregunta a un resolutor recursivo (normalmente el de su proveedor de internet o un servicio público).
2. Si la respuesta no está en caché, el resolutor pregunta a un servidor raíz, que le remite a los servidores del TLD.
3. Los servidores del TLD le remiten a los servidores autoritativos de su dominio.
4. El servidor autoritativo devuelve el registro y el resolutor lo guarda en caché durante su TTL.

Anatomía de un registro de recursos

Todo registro consta de las mismas cinco partes, que se ven claramente en la sintaxis estándar de un archivo de zona:

www.ejemplo.es.   3600   IN   A   192.0.2.10
nombre            TTL    clase tipo datos

• Nombre: el host al que pertenece el registro. El punto final indica un nombre completo; en archivos de zona y en muchos paneles, @ representa el dominio raíz (el dominio sin subdominio).
• TTL: tiempo de vida en segundos, que indica a los resolutores cuánto pueden guardar la respuesta.
• Clase: casi siempre IN, de internet.
• Tipo: A, AAAA, CNAME, MX, TXT, etc.
• Datos: el valor, cuyo formato depende del tipo.

Los tipos de registro DNS más habituales

Registros A y AAAA: apuntar nombres a servidores

Un registro A contiene una dirección IPv4 y un registro AAAA, una dirección IPv6. Un nombre puede tener varios de cada tipo y los resolutores devolverán todos, lo que ofrece una forma sencilla de repartir la carga. Si su proveedor de alojamiento admite IPv6, publique ambos para que los clientes en redes solo IPv6 o de doble pila se conecten directamente.

@     3600  IN  A     192.0.2.10
@     3600  IN  AAAA  2001:db8::10
www   3600  IN  A     192.0.2.10

Cuando se cambia de servidor, son precisamente los registros A y AAAA los que hay que modificar. Saber a qué red pertenece una dirección ayuda a diagnosticar problemas; una herramienta como el comprobador de hosting de TLDix muestra qué proveedor opera una IP determinada.

Registros CNAME: alias y sus límites

Un CNAME indica que un nombre es un alias de otro nombre canónico. Los resolutores siguen la cadena y devuelven los registros del destino. Son muy prácticos para apuntar subdominios a servicios que usted no controla, como una tienda alojada, una CDN o una página de estado, porque el proveedor puede cambiar sus IP sin que usted tenga que tocar nada.

tienda  3600  IN  CNAME  stores.proveedor.example.
estado  3600  IN  CNAME  ejemplo.statuspage.example.

Reglas que no se deben romper

• Un nombre con CNAME no puede tener ningún otro tipo de registro (RFC 1034, aclarado en la RFC 2181). No se puede combinar un CNAME y un MX en el mismo nombre.
• Como el dominio raíz siempre tiene registros SOA y NS, no se puede usar un CNAME estándar en él. Muchos proveedores ofrecen soluciones propias como ALIAS, ANAME o «CNAME flattening», y el tipo de registro HTTPS (RFC 9460) es otra opción.
• Los registros MX y NS deben apuntar a un nombre con registros A o AAAA, nunca a un CNAME.
• Evite cadenas largas de CNAME: cada salto añade tiempo de resolución y un nuevo punto de fallo.

Registros MX: el enrutamiento del correo

Los registros MX indican a los servidores emisores dónde entregar el correo de su dominio. Cada registro lleva un número de preferencia: los valores más bajos se prueban primero y los registros con la misma preferencia se reparten la carga.

@  3600  IN  MX  10 mx1.proveedorcorreo.example.
@  3600  IN  MX  20 mx2.proveedorcorreo.example.

Si un dominio no tiene MX, los emisores recurren a su registro A o AAAA, algo que casi nunca interesa. Para dominios que no deben recibir correo, la RFC 7505 define el «null MX»: un único registro con preferencia 0 y un punto como destino.

Registros TXT: verificación y autenticación de correo

Los registros TXT almacenan texto arbitrario y con el tiempo se han convertido en el lugar donde se publican políticas y pruebas de propiedad. Buscadores, autoridades de certificación y plataformas SaaS suelen pedir que añada un TXT con un código para demostrar que controla el dominio. Los tres usos más importantes tienen que ver con el correo:

• SPF (RFC 7208) enumera los servidores autorizados a enviar correo en nombre de su dominio, por ejemplo v=spf1 include:_spf.proveedorcorreo.example -all. Publique un solo registro SPF por nombre.
• DKIM (RFC 6376) publica una clave pública bajo un selector como s1._domainkey, con la que los receptores verifican las firmas de los mensajes.
• DMARC (RFC 7489) se ubica en _dmarc e indica qué hacer cuando fallan SPF y DKIM, por ejemplo v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.es.

Cada cadena TXT tiene un máximo de 255 caracteres, pero un registro puede contener varias cadenas que se concatenan; así se almacenan las claves DKIM largas.

NS, SOA y CAA: los registros que gobiernan la zona

Registros NS

Los registros NS enumeran los servidores autoritativos de una zona y deben coincidir en dos niveles: en la zona del TLD, configurada a través del registrador, y dentro de su propia zona. Una discrepancia provoca respuestas incoherentes difíciles de diagnosticar. Lo habitual es usar al menos dos servidores de nombres en redes distintas.

El registro SOA

@  IN  SOA  ns1.ejemplo.net. hostmaster.ejemplo.es. (
        2026100701 ; serie
        7200       ; refresco
        3600       ; reintento
        1209600    ; expiración
        3600 )     ; TTL de caché negativa

El número de serie debe aumentar cada vez que cambia la zona para que los servidores secundarios recojan la actualización; es habitual un formato basado en la fecha como el del ejemplo. El último campo determina cuánto tiempo se guarda en caché una respuesta de «no existe» (RFC 2308).

Registros CAA

Los registros CAA indican qué autoridades de certificación pueden emitir certificados TLS para su dominio. Desde 2017, las autoridades de confianza pública deben comprobarlos antes de emitir. Añadir 0 issue "letsencrypt.org" significa que solo esa autoridad puede hacerlo, lo que reduce el riesgo de certificados emitidos por error.

TTL, propagación y comprobación de registros

En el DNS no existe un envío global de cambios: estos se hacen visibles a medida que caducan las copias en caché. Con un TTL de 86400, algunos resolutores podrían seguir sirviendo el valor antiguo hasta un día. Antes de una migración planificada, lo sensato es bajar el TTL a 300 segundos uno o dos días antes, hacer el cambio, comprobarlo y volver a subir el TTL.

La herramienta dig es la forma más fiable de ver lo que realmente está publicado:

dig ejemplo.es A
dig ejemplo.es MX +short
dig _dmarc.ejemplo.es TXT
dig @ns1.ejemplo.net ejemplo.es SOA
dig ejemplo.es NS +trace

Preguntar directamente al servidor autoritativo con @ muestra el valor actual sin pasar por ninguna caché. La opción +trace sigue la delegación desde la raíz, algo muy útil cuando se sospecha una discrepancia entre el registrador y el proveedor DNS.

Errores frecuentes y cómo evitarlos

• Dejar caducar el dominio. Todos los registros dejan de funcionar en cuanto se suspende el dominio. Vigile las fechas de caducidad: la consulta de dominios de TLDix muestra el estado del registro y los servidores de nombres, y la documentación describe las alertas de renovación.
• Olvidar el punto final en los archivos de zona, lo que convierte mail.ejemplo.es en mail.ejemplo.es.ejemplo.es.
• Dos registros SPF en el mismo nombre, lo que provoca un error permanente en la evaluación SPF.
• Conflictos de CNAME en el dominio raíz o junto a registros MX y TXT.
• Registros obsoletos que apuntan a recursos en la nube ya eliminados, lo que puede permitir la toma de control de subdominios. Elimine los registros al retirar un servicio.

Una vez que domine estos pocos tipos de registro, casi cualquier tarea DNS se reduce a elegir el tipo adecuado, escribir el valor con cuidado y verificar el resultado con dig.