Registros DNS para desarrolladores — A, CNAME, MX, TXT y el TTL que te hizo esperar 48 horas

Compraste un dominio, lo dirigiste a algún lugar y ahora estás mirando un navegador que aún muestra el sitio antiguo. O configuraste mal tus registros MX y descubriste que cuando los correos electrónicos comienzan a rechazarse. DNS es uno de esos temas que los desarrolladores ignoran la mayoría de las veces hasta que se les pone a prueba — y cuando lo hacen, el ciclo de retroalimentación es lento y doloroso.

Este no es un tutorial para personas que nunca han escuchado de DNS. Es una referencia para desarrolladores que conocen qué es un dominio, pero que cada vez que necesitan añadir un tipo de registro que no han tocado en seis meses, se dirigen a Stack Overflow.

Cómo funciona realmente DNS (versión de 30 segundos)

Cuando un navegador resuelve example.com, pide a un resolución recursiva (normalmente tu proveedor de servicios o 8.8.8.8). El resolución verifica su caché. Si hay un acierto en el caché, devuelve la respuesta almacenada. Si no, avanza por el árbol de DNS — servidores raíz → servidores de dominio de TLD (.com) → el servidor autoritativo de tu dominio — y almacena el resultado durante el tiempo que indique el TTL.

Cada registro DNS tiene un tipo, un nombre, un valor y un TTL. Eso es todo. La complejidad viene de saber qué tipo hace qué y en qué puntos los registros interactúan de maneras no obvias.

Los tipos de registro que realmente usarás

Registro A — Dirección IP para un nombre de host

Asigna un nombre de host a una dirección IPv4. Este es el registro más común que manipularás.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

El problema: puedes tener múltiples registros A para el mismo nombre de host. DNS devolverá todos ellos, y el cliente elegirá uno (normalmente mediante rotación). Esto es una configuración sencilla de balanceo de carga — pero si uno de esos IPs se cae, DNS no tiene comprobaciones de salud. Continuará sirviendo la IP dañada hasta que expire el TTL y lo elimines.

Para IPv6, el equivalente es un registro AAAA. Mismo concepto, dirección de 128 bits en lugar de 32 bits.

Registro CNAME — Alias a otro nombre de host

Punta un nombre de host a otro nombre de host (no a una IP). El resolución sigue la cadena hasta que encuentra un registro A.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A — cuándo usar cuál: Si estás apuntando a un servicio que te da un nombre de host (Netlify, Vercel, GitHub Pages, Heroku, la mayoría de los CDNs), usa un CNAME. Si tienes una IP estática, usa un registro A. Simple.

La regla dura: no puedes colocar un CNAME en el apex de tu zona (el dominio puro — example.com, no www.example.com). El RFC 1034 lo prohibe porque el apex debe contener registros SOA y NS, y un CNAME en el mismo nombre causaría conflicto. Cuando Netlify o Vercel te dicen que agregues un CNAME para tu dominio raíz, lo que realmente quieren decir es que utilices su proveedor de DNS que soporte registros ANAME o ALIAS, una extensión propietaria que se comporta como un CNAME pero que resuelve a registros A en el nivel de zona.

También: nunca apuntes un CNAME a otro CNAME si puedes evitarlo. Técnicamente legal, pero cada salto en la cadena es una consulta DNS adicional. Lo que es más importante, si el CNAME intermedio se rompe, tu registro también se rompe.

Registro MX — Ruteo de correo

Indica a otros servidores de correo dónde entregar el correo para tu dominio. Los registros MX tienen un número de prioridad — número más bajo = mayor prioridad.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Si mail1 no está disponible, los servidores de envío intentarán mail2. Esto es un fallo adecuado, no un balanceo de carga — no estás dividiendo el tráfico, estás especificando un orden de preferencia.

El error que cometen los desarrolladores: apuntar MX a una dirección IP o a un CNAME. Los valores de MX deben apuntar a registros A (nombres de host), no a IPs ni a CNAMEs. Algunos proveedores de DNS te permitirán guardar esta configuración incorrecta sin advertencia, y entonces tus correos electrónicos fallarán silenciosamente.

Si estás configurando Google Workspace o Microsoft 365, te darán un conjunto de registros MX. No modifiques los números de prioridad pensando que estás siendo inteligente — la lógica de ruteo de correo depende de que sean exactos.

Registro TXT — Texto arbitrario, principalmente para verificación y autenticación de correo

Los registros TXT contienen cadenas de texto libres. En la práctica, se usan para tres cosas:

• Verificación de dominio — Google Search Console, Stripe, GitHub y cientos de otros servicios te pedirán que agregues un registro TXT para demostrar que posees el dominio
• SPF (Framework de Política de Envío) — especifica cuáles servidores de correo están autorizados para enviar correo por tu dominio
• DKIM y DMARC — registros de autenticación de correo que previenen el engaño

Un registro SPF se ve así:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Esto dice: Google y SendGrid están autorizados para enviar correo por este dominio; cualquier otro debe tratarse con sospecha (~all = fallo suave, -all = fallo duro).

Un registro DMARC está en _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Lo importante es: solo puedes tener un registro SPF TXT por dominio. Si agregas un segundo registro (porque un nuevo servicio te lo pide), ambos registros existirán, los servidores de correo verán políticas contradictorias y la autenticación de correo se romperá. En su lugar, únelos: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Registro NS — Delegación de servidores de nombres

Especifica cuáles servidores de nombres son autoritativos para tu dominio. Normalmente los configuras en tu registrador de dominios, no directamente en tu zona DNS. Cuando migras de un proveedor de DNS a otro (por ejemplo, de los servidores de GoDaddy a Cloudflare), estás actualizando los registros NS en el nivel del registrador.

La propagación de registros NS es la razón por la que las migraciones de dominios son lentas. Los TTL de NS suelen ser de 24 a 48 horas, y los cambios en el registrador tienen su propia demora de propagación encima de eso.

TTL — el número que te hizo esperar 48 horas

El TTL (Time To Live) es un número en segundos. Dice a los resolutores en caché durante cuánto tiempo deben recordar una respuesta antes de volver a pedirla. Un TTL de 300 significa cinco minutos. Un TTL de 172800 significa 48 horas.

Cuando cambias un registro DNS, la respuesta antigua sigue en caché en todos lados hasta que se alcanza el antiguo TTL. Si tu registro A tenía un TTL de 48 horas y acaba de cambiar la IP, algunos usuarios podrán llegar al servidor antiguo durante hasta dos días — y no hay nada que puedas hacer una vez que se ha hecho el cambio.

La solución es bajar el TTL antes de hacer el cambio. La práctica estándar para migraciones planificadas:

1. Bajar el TTL a 300 (5 minutos) al menos 48 horas antes de la migración — debes esperar que expire el TTL alto primero
2. Hacer el cambio DNS
3. Esperar entre 5 y 10 minutos para la propagación
4. Aumentar el TTL de nuevo a un valor razonable (3600–86400) una vez que hayas confirmado que la nueva configuración funciona

Si olvidas el paso 1 y vas directo al paso 2 con un TTL alto, estás atrapado. Puedes bajar el TTL ahora, pero eso solo acorta el tiempo de espera para los resolutores que aún no lo han caché. Cualquier cosa que ya haya caché debe esperar hasta que expire el TTL original.

Referencia rápida

Registro	Punta a	Uso común	Punto importante
A	Dirección IPv4	Nombre de host → IP del servidor	Sin comprobaciones de salud — los IPs dañados permanecen en rotación hasta que expire el TTL
AAAA	Dirección IPv6	Nombre de host → IP del servidor IPv6	Fácil de olvidar agregar junto al registro A para soporte dual-stack
CNAME	Otro nombre de host	Alias, ruteo de CDNs o plataformas en la nube	No se puede usar en el apex de la zona; MX/NS no pueden apuntar a un CNAME
MX	Nombre de host (registro A)	Ruteo de entrega de correo	El valor debe ser un nombre de host, no una IP; los números de prioridad importan
TXT	Texto libre	SPF, DKIM, DMARC, verificación de dominio	Solo se permite un registro SPF por dominio — únelo, no agregues uno
NS	Nombre del servidor de nombres	Delegación de DNS	Los cambios pasan por el registrador y se propagan lentamente
CAA	Dominio del CA	Qué CAs pueden emitir certificados SSL para tu dominio	Fácil de bloquearte de la renovación del certificado por configuración incorrecta

Cosas que te ahorrarán tiempo

Usa dig directamente, no mediante una herramienta web. dig @8.8.8.8 example.com A Evita tu resolución local y muestra exactamente lo que ve Google DNS. Agrega +short para solo la respuesta. Agrega +trace para recorrer toda la cadena de resolución.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Verifica el TTL antes de cualquier migración. Ejecuta dig example.com A y mira el número en la tercera columna de la sección de respuesta. Ese es el tiempo (en segundos) que podrías estar esperando si cambias el registro ahora sin haber bajado el TTL primero.

Los registros proxy de Cloudflare no exponen tu IP real. Cuando activas el cloud naranja de Cloudflare en un registro, la IP expuesta al mundo es la de Cloudflare, no la tuya. Esto normalmente es lo que deseas para protección contra DDoS — pero significa que dig no mostrará la IP real de tu servidor, y las herramientas que probar directamente tu IP no funcionarán como esperas.

También te puede interesar