Qué es el DNS y para qué sirven los registros A, AAAA, CNAME, MX y TXT

El DNS (Domain Name System) es el sistema que traduce nombres de dominio legibles, como blog.aimran.es, en las direcciones IP que los ordenadores usan para conectarse. Funciona como una base de datos distribuida y jerárquica: cuando escribes un dominio, tu dispositivo pregunta a una cadena de servidores hasta obtener la respuesta, que se guarda en caché durante el tiempo que indique el TTL. La configuración de un dominio se compone de registros de distintos tipos: A y AAAA apuntan a direcciones IP, CNAME crea un alias hacia otro nombre, MX indica dónde se recibe el correo y TXT almacena texto para verificaciones y políticas de correo.

Este artículo explica cómo se resuelve un nombre, qué hace cada registro, por qué los cambios “tardan en propagarse” y cómo comprobarlo todo desde la terminal.

Cómo se resuelve un dominio

Cuando el navegador necesita la IP de blog.aimran.es:

1. Consulta la caché local (del sistema operativo o del navegador). Si hay una respuesta vigente, termina aquí.
2. Si no, pregunta al resolutor recursivo configurado (el de tu operador, o uno público como 1.1.1.1 o 8.8.8.8).
3. El resolutor, si tampoco lo tiene en caché, pregunta a los servidores raíz, que le indican los servidores del dominio de primer nivel (.es).
4. Los servidores de .es le indican los servidores autoritativos de aimran.es (los registros NS del dominio).
5. El servidor autoritativo responde con el registro solicitado, y el resolutor lo devuelve al navegador y lo guarda en caché durante el TTL.

Todo esto ocurre en milisegundos y, gracias a las cachés, la mayoría de las veces no llega a los pasos 3 y 4.

Los tipos de registro más usados

Registro	Qué hace	Ejemplo de valor
A	Asocia un nombre a una dirección IPv4	203.0.113.10
AAAA	Asocia un nombre a una dirección IPv6	2001:db8::10
CNAME	Alias: indica que un nombre es equivalente a otro nombre	blog.aimran.es → sitio.proveedor-hosting.net
MX	Servidores que reciben el correo del dominio, con prioridad	10 mail.proveedor.com
TXT	Texto libre: verificación de propiedad, SPF, DKIM, DMARC	v=spf1 include:_spf.proveedor.com -all
NS	Servidores de nombres autoritativos del dominio	ns1.proveedor-dns.com
CAA	Qué autoridades pueden emitir certificados TLS para el dominio	0 issue "letsencrypt.org"

A y AAAA

Son los registros “finales”: dan la IP. Un mismo nombre puede tener varios registros A (el cliente elige uno), lo que se usa como reparto de carga básico. Si tu servidor tiene IPv6, añade el AAAA; cada vez más redes móviles lo prefieren.

CNAME: alias con una restricción importante

Un CNAME dice “este nombre es otro nombre”: blog.aimran.es → sitio.proveedor.net, y el resolutor continúa resolviendo el segundo. Es lo habitual para subdominios alojados en plataformas (Netlify, Vercel, GitHub Pages, Cloudflare Pages), porque el proveedor puede cambiar sus IPs sin que tú toques nada.

La restricción, definida en la RFC 1034 (sección 3.6.2): un nombre con CNAME no puede tener ningún otro registro. Y el dominio raíz (aimran.es, el apex) siempre tiene registros NS y SOA, así que no puede ser un CNAME. Para apuntar el apex a una plataforma hay dos salidas: usar los registros A/AAAA que indique el proveedor, o usar las funciones no estándar que ofrecen muchos servidores DNS (ALIAS, ANAME o “CNAME flattening”), que resuelven el alias en el lado del servidor y devuelven una IP.

MX: dónde llega el correo

Los registros MX indican los servidores de correo entrante y su prioridad (menor número, mayor prioridad). Si contratas el correo con un proveedor, te dará sus valores exactos. Sin MX, el correo a tu dominio no tiene adónde ir.

TXT: verificaciones y políticas antispam

Los TXT guardan texto arbitrario y se usan sobre todo para:

• Verificar la propiedad del dominio ante servicios como Google Search Console o proveedores de correo (te piden añadir un valor concreto).
• SPF (RFC 7208): qué servidores pueden enviar correo en nombre de tu dominio.
• DKIM: la clave pública que firma tus correos salientes.
• DMARC: qué hacer con los correos que no superan SPF/DKIM y adónde enviar informes.

Si envías correo desde el dominio (aunque sea solo el formulario de contacto), configurar SPF, DKIM y DMARC es lo que evita acabar en la carpeta de spam.

TTL y la famosa “propagación”

Cada registro lleva un TTL (time to live) en segundos: el tiempo que los resolutores pueden guardar la respuesta en caché. Con un TTL de 3600, un resolutor que consultó tu A hace diez minutos seguirá devolviendo la IP antigua durante otros cincuenta, aunque ya la hayas cambiado.

Eso es toda la “propagación”: no hay un proceso que empuje el cambio por el mundo, solo cachés que expiran a distinto ritmo. De ahí la técnica estándar para una migración: baja el TTL (por ejemplo, a 300) uno o dos días antes del cambio, haz el cambio, y cuando todo funcione vuelve a subirlo.

Cómo comprobar los registros con dig

dig viene instalado en macOS y en la mayoría de distribuciones Linux (paquete dnsutils o bind-utils); en Windows puedes usar nslookup o Resolve-DnsName en PowerShell.

# Registro A (solo la respuesta)
dig +short blog.aimran.es A

# Registros MX y TXT del dominio raíz
dig +short aimran.es MX
dig +short aimran.es TXT

# Preguntar directamente al servidor autoritativo, saltándose las cachés
dig @ns1.proveedor-dns.com aimran.es A

# Ver el TTL restante en la caché de un resolutor público
dig @1.1.1.1 blog.aimran.es A

Consultar directamente al servidor autoritativo (@servidor) es la forma de saber si tu cambio ya está hecho, independientemente de lo que digan las cachés.

Errores habituales

1. Intentar poner un CNAME en el apex o junto a otros registros del mismo nombre: el panel lo rechazará o el dominio dejará de funcionar.
2. Cambiar registros con un TTL alto y esperar que el cambio sea inmediato.
3. Olvidar el AAAA al migrar: el A apunta al servidor nuevo, el AAAA al antiguo, y los usuarios con IPv6 ven la web vieja.
4. Añadir varios registros SPF: solo puede haber uno; combina los include: en el mismo.
5. No fijar un CAA: no es obligatorio, pero limitar qué autoridades pueden emitir certificados para tu dominio es una medida de seguridad barata.

Conclusión

El DNS es una cadena de preguntas con caché en cada eslabón. Los registros A/AAAA dan la IP, el CNAME delega en otro nombre (nunca en el apex), el MX recibe el correo y los TXT verifican y protegen tu identidad al enviarlo. Si entiendes el TTL, dejas de esperar “propagaciones” y planificas los cambios; si usas dig contra el servidor autoritativo, sabes en todo momento qué está configurado de verdad.