← Volver al blogGuías

Tipos de registros DNS: A, AAAA, CNAME, MX, TXT y los demás

Para qué sirve cada tipo de registro DNS, las reglas que más fallos causan (CNAME en el ápex, destinos MX, TXT largos) y cómo consultarlos con dig.

Publicado: · 7 min de lectura

Una zona DNS es una lista de registros de recursos. Todos tienen las mismas cinco partes:

www.example.com.   3600   IN   A   192.0.2.10
└── name           └ TTL  └class └type └ data

El nombre es lo que se consulta; el TTL indica cuántos segundos puede un resolver guardar la respuesta en caché (véase qué es el TTL en DNS); la clase es prácticamente siempre IN, y el tipo decide cómo se interpretan los datos. Esta guía repasa los tipos de registros DNS que de verdad se encuentran en la práctica, con las reglas que provocan caídas reales.

Referencia rápida

Tipo Para qué sirve Ejemplo de datos
A dirección IPv4 192.0.2.10
AAAA dirección IPv6 2001:db8::10
CNAME alias de otro nombre shop.hosting.example.
MX servidores de correo del dominio 10 mx1.mail.example.
TXT texto libre: SPF, DKIM, DMARC, verificaciones "v=spf1 -all"
NS servidores de nombres responsables de una zona ns1.dns.example.
SOA metadatos de la zona, uno por zona número de serie, temporizadores
PTR resolución inversa: de dirección a nombre mail.example.com.
SRV host y puerto de un servicio 10 5 5060 sip.example.com.
CAA qué CA pueden emitir certificados 0 issue "ca.example"
DS, DNSKEY, RRSIG DNSSEC claves y firmas
HTTPS, SVCB parámetros de servicio para HTTPS 1 . alpn="h2,h3"

A y AAAA: direcciones

A asocia un nombre a una dirección IPv4; AAAA, a una IPv6. Un nombre puede tener varios registros de cada tipo: los resolvers los devuelven todos y el cliente elige uno, lo que reparte la carga de forma rudimentaria pero no ofrece conmutación por error con ninguna garantía.

$ dig +short www.example.com A
192.0.2.10
$ dig +short www.example.com AAAA
2001:db8::10

Publique un registro AAAA solo si el servidor responde de verdad por IPv6. Una ruta IPv6 rota hace que el sitio vaya lento o sea inaccesible para parte de los usuarios mientras "a usted le funciona".

CNAME: los alias y sus dos reglas

Un CNAME dice: "este nombre es un alias; consulte ese otro nombre en su lugar". El resolver reinicia la consulta con el destino.

shop.example.com.   3600  IN  CNAME  stores.hosting.example.

Hay dos reglas que vienen de los estándares de DNS, no de las preferencias de ningún proveedor:

  1. Un nombre con CNAME no puede tener ningún otro registro. Ni MX, ni TXT, ni nada (con la excepción de los registros de DNSSEC).
  2. Por tanto, no cabe un CNAME en el ápex de la zona. example.com tiene que llevar los registros SOA y NS, así que no puede ser un CNAME.

Los proveedores sortean la segunda regla con "ALIAS", "ANAME" o "CNAME flattening": el propio proveedor DNS resuelve el destino y responde con registros A/AAAA. Funciona, pero es una función del proveedor, no un tipo de registro, y no sobrevive a la exportación de la zona a un proveedor que no la tenga.

Más consejos sobre CNAME: no apunte registros MX ni NS a un CNAME y evite las cadenas largas. Cada salto es otra consulta y otra cosa que puede fallar.

MX: adónde va el correo

Los registros MX nombran los servidores que aceptan correo para el dominio, cada uno con un número de preferencia. El número más bajo se prueba primero; los números iguales se reparten la carga.

example.com.  3600  IN  MX  10 mx1.mail.example.
example.com.  3600  IN  MX  20 mx2.mail.example.

El destino debe ser un nombre de host con registros A/AAAA: ni una dirección IP ni un CNAME. Si un dominio no tiene ningún MX, los remitentes recurren al registro A del dominio, cosa que rara vez es lo deseado. Un dominio que no recibe correo puede declararlo de forma explícita con un MX nulo: 0 .

SPF, DKIM y DMARC, que se construyen sobre MX y TXT, tienen su propia guía: MX, SPF, DKIM y DMARC explicados.

TXT: texto con convenciones

TXT contiene cadenas arbitrarias. Su importancia real viene de las convenciones que se apoyan en él:

  • SPF en el propio dominio: "v=spf1 include:_spf.mail.example -all". Exactamente un registro SPF por nombre; dos son un error permanente.
  • DKIM en selector._domainkey.example.com.
  • DMARC en _dmarc.example.com.
  • Cadenas de verificación de propiedad para consolas de buscadores, herramientas SaaS y emisión de certificados.

Una sola cadena dentro de un registro TXT está limitada a 255 bytes. Los valores más largos, típicamente las claves DKIM de 2048 bits, se dividen en varias cadenas entrecomilladas dentro de un mismo registro, y quien las lee las une sin ningún separador:

sel1._domainkey  IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
                          "...AQ8AMIIBCgKCAQEA" )

La mayoría de los paneles de control hace la división por usted. Si la hace a mano, no añada un espacio en la unión.

NS y SOA: la estructura de la zona

Los registros NS enumeran los servidores de nombres autoritativos. Existen por duplicado: en la zona padre (la delegación, que se cambia en el registrador) y dentro de la propia zona. Los dos conjuntos deberían coincidir. Los registros NS en un subdominio delegan ese subdominio en otros servidores.

SOA es el registro único que encabeza cada zona:

example.com. 3600 IN SOA ns1.dns.example. hostmaster.example.com. (
    2026092001 ; serial
    7200       ; refresh
    3600       ; retry
    1209600    ; expire
    300 )      ; negative-caching TTL

El número de serie avisa a los servidores secundarios de que la zona ha cambiado. El último campo es el que casi todo el mundo pasa por alto: controla cuánto tiempo guardan los resolvers en caché la respuesta "este nombre no existe". Por eso un registro creado un minuto después de que alguien lo consultara puede seguir invisible durante un rato.

Mover los registros NS es un proyecto en sí mismo y necesita un plan propio.

PTR: resolución inversa

Un registro PTR asocia una dirección a un nombre. Vive en una zona especial (in-addr.arpa para IPv4, ip6.arpa para IPv6) controlada por quien posee el bloque de direcciones IP, normalmente el proveedor de hosting o de acceso a Internet, y no por usted en la zona de su dominio.

$ dig +short -x 192.0.2.25
mail.example.com.

Importa sobre todo para los servidores de correo. El glosario lo explica en DNS inverso.

SRV: servicios con puerto

Los registros SRV permiten a un cliente encontrar el host y el puerto de un servicio, bajo un nombre de la forma _servicio._proto.nombre:

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
;                                  prio weight port target

Los usan SIP, XMPP, Matrix, algunos servicios de Microsoft y otros. Los navegadores no usan SRV para los sitios web.

CAA: quién puede emitir certificados

CAA enumera las autoridades de certificación autorizadas a emitir para el dominio. Toda CA pública debe comprobarlo antes de emitir.

example.com.  IN  CAA  0 issue "ca.example"
example.com.  IN  CAA  0 issuewild ";"

Si no hay registro CAA, cualquier CA puede emitir. Más detalle en el glosario: registro CAA.

Registros de DNSSEC

DNSKEY contiene las claves públicas de la zona; RRSIG, las firmas de cada conjunto de registros; NSEC/NSEC3 demuestran que un nombre no existe, y DS, en la zona padre, enlaza la clave de la zona hija con la cadena de confianza. El proveedor DNS los genera todos salvo DS, que usted (o el proveedor) envía a través del registrador.

HTTPS y SVCB

El registro HTTPS (una forma especial de SVCB) permite que un navegador sepa, en la misma respuesta DNS, que un sitio admite HTTP/2 o HTTP/3, qué direcciones usar y, opcionalmente, un destino de alias, incluso en el ápex. Las grandes CDN lo publican automáticamente. Rara vez se escribe a mano, pero aparece en las consultas:

$ dig +short example.com HTTPS
1 . alpn="h2,h3"

¿Y el tipo ANY?

dig example.com ANY devolvía antes todo lo que tenía un servidor. Hoy muchos servidores contestan con una respuesta mínima, porque ANY se usó de forma abusiva en ataques de amplificación. Para ver los registros de una zona, consulte cada tipo que le interese. No existe ninguna consulta pública que enumere todos los nombres de una zona; las transferencias de zona (AXFR) están restringidas a los secundarios autorizados.

Errores frecuentes

  • Un CNAME en el ápex, o un CNAME junto a MX/TXT en el mismo nombre.
  • Un MX que apunta a una dirección IP o a un CNAME.
  • Dos registros TXT de SPF en un mismo nombre.
  • Olvidar el punto final en un archivo de zona, de modo que mx1.mail.example se convierte en mx1.mail.example.example.com.. Los paneles de control difieren en si esperan el punto o no; compruebe el resultado con dig.
  • Un registro AAAA para un servidor sin IPv6 operativo.
  • Crear un registro en www y esperar que el dominio sin prefijo lo siga, o al revés. Son nombres distintos.
  • Olvidar el TTL de caché negativa cuando un registro nuevo "no aparece".

Compruébelo con OrbitProbe

La consulta DNS de OrbitProbe pregunta de una vez por los registros A, AAAA, CNAME, MX, TXT, NS, SOA y CAA de un nombre y muestra el TTL de cada respuesta, para comparar lo publicado con lo que se pretendía publicar. Ejecútela por separado para el dominio sin prefijo y para www: son nombres distintos con registros distintos. Y si el problema de fondo es que el correo acaba en spam, siga con la lista de comprobación DNS para correos que llegan a spam.