Registros DNS: guía de la A a ALIAS

DNS (Domain Name System) — sistema distribuido que, a partir del nombre de dominio, indica dónde está el sitio, a dónde entregar el correo y a quién pertenece el dominio. Cada respuesta se guarda en la zona del dominio como un registro de un tipo determinado. Este artículo es un manual de los tipos de registros. Cómo configurar DNS para sitio y correo paso a paso se explica en el ciclo «Настройка DNS для почты и сайта»: registros básicos A y MX, SPF, DKIM y DMARC, configuración y verificación, BIMI.

Dos principios: TTL y delegación

TTL — tiempo de vida del registro en caché

Cada registro tiene un TTL — número de segundos durante los cuales los resolvers y clientes pueden almacenar la respuesta sin volver a preguntar.

Para registros estables (A, MX) normalmente se pone entre una hora y un día. Antes de una migración se reduce el TTL con antelación: sobre esto — en la sección «TTL al migrar» más abajo.

Delegación y servidores NS

La zona padre (por ejemplo, .ru o .com) delega el control de su zona example.ru a los servidores indicados en los registros NS. Debe haber al menos dos servidores, preferiblemente en redes diferentes: esto lo exige el RFC 2182 y las reglas de la mayoría de los registradores. Si un servidor deja de responder, los resolvers consultarán al otro.

Registros básicos

Un nombre con CNAME no puede tener otros registros (RFC 1034, RFC 2181). Por eso no se puede poner CNAME en la raíz del dominio (example.ru): allí siempre hay SOA y NS.

Registros de servicio

NS — servidores responsables de la zona

Los registros NS existen en dos sitios: en el registrador (en la zona padre, eso es la delegación) y en la propia zona. Deben coincidir — la discrepancia hace que algunos resolvers reciban respuestas obsoletas.

SOA — parámetros de la zona

Uno por zona, describe el servidor primario, la dirección del responsable y los temporizadores para que los secundarios actualicen.

example.ru. IN SOA ns1.example.ru. admin.example.ru. (
    2025111101   ; Serial (AAAAMMDDNN)
    7200         ; Refresh — con qué frecuencia los servidores secundarios verifican la zona
    3600         ; Retry — reintento en caso de fallo
    1209600      ; Expire — cuándo el servidor secundario deja de responder sin contacto con el primario
    86400        ; Minimum — TTL de respuestas negativas (RFC 2308)
)

El número de serie se incrementa con cada cambio en la zona; de lo contrario los servidores secundarios no recogerán la actualización. El formato AAAAMMDDNN (fecha y número de edición del día) es conveniente, pero no obligatorio. En proveedores de DNS en la nube el SOA suele gestionarlo el propio proveedor.

TXT — texto arbitrario

Se usa para SPF, DKIM, DMARC y la verificación de propiedad del dominio:

example.ru. TXT "v=spf1 mx include:_spf.yandex.net -all"
example.ru. TXT "yandex-verification=abc123"
_dmarc.example.ru. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru"

En detalle sobre registros de correo — en la parte 2 del ciclo DNS.

CAA — quién tiene permitido emitir certificados

El registro limita la lista de autoridades de certificación que pueden emitir un certificado TLS para el dominio (RFC 8659):

example.ru. CAA 0 issue "letsencrypt.org"

Si no hay registros CAA, cualquier autoridad puede emitir. Sobre autoridades de certificación gratuitas — en el artículo «Más allá de Let’s Encrypt», y sobre emisión vía DNS — en «Certificados SSL a través de DNS».

PTR — registro inverso

Asocia un nombre a una dirección IP. Se guarda en la zona in-addr.arpa (para IPv4) y lo configura el propietario de las direcciones — normalmente el proveedor de hosting, no la zona del dominio. Para un servidor de correo PTR es obligatorio: sin él, los correos a menudo van a spam.

SRV — servidor y puerto del servicio

SRV indica en qué host y puerto funciona el servicio:

_minecraft._tcp.play.example.ru. IN SRV 10 5 25565 mc.example.ru.

SRV se usa en SIP, XMPP, Kerberos, LDAP en Active Directory y algunos juegos.

ALIAS (ANAME) y CNAME en la raíz del dominio

La restricción del CNAME es un problema cuando la raíz del dominio debe apuntar a un nombre de una plataforma (por ejemplo, a la dirección del balanceador de un proveedor en la nube). Los proveedores DNS lo resuelven de distintas formas: resuelven el nombre objetivo ellos mismos y devuelven al cliente registros A/AAAA listos.

No es un tipo de registro estándar del RFC, sino una función del proveedor: al migrar a otro proveedor DNS habrá que configurarlo de nuevo.

GeoDNS — tecnología, no tipo de registro

GeoDNS devuelve respuestas diferentes según de dónde provenga la consulta: por ejemplo, a usuarios desde Europa la dirección del servidor europeo, desde Asia la del servidor asiático. La localización se determina por la dirección del resolver o por la subred del cliente si el resolver la transmite (EDNS Client Subnet, RFC 7871). Esta ruta la ofrecen CDNs y proveedores DNS, por ejemplo Route 53 (geolocation routing).

Otros registros

Cómo comprobar los registros

dig NS example.ru +trace           # delegación desde la raíz hasta sus NS
dig A example.ru                   # dirección del sitio
dig MX example.ru                  # servidores de correo
dig TXT example.ru                 # SPF y verificaciones
dig TXT _dmarc.example.ru          # DMARC
dig SOA example.ru                 # parámetros de la zona, número de serie
dig CAA example.ru                 # centros de certificación permitidos
dig -x 192.0.2.1                   # PTR para la dirección
dig example.ru +dnssec             # firmas DNSSEC

Para comprobar un servidor concreto y no la caché del resolver, indícalo explícitamente: dig A example.ru @ns1.example.ru.

TTL al migrar

1. Dos días antes (o durante un período no menor que el TTL actual) reduzca el TTL de los registros que vaya a migrar a 300 segundos.
2. Espere a que expire el TTL antiguo: solo después de eso todos los resolvers empezarán a preguntar con frecuencia.
3. Cambie los registros.
4. Cuando todo esté verificado, vuelva a poner el TTL a una hora o a un día.

Resumen

Para sitio y correo a la mayoría de empresas les basta con A/AAAA, MX, TXT (SPF, DKIM, DMARC), NS y CAA. SRV, ALIAS y GeoDNS son necesarios en casos concretos: servicios en puertos no estándar, raíz del dominio en una plataforma en la nube, reparto de tráfico por regiones.

Fuentes:

• RFC 1034 y RFC 1035 — fundamentos de DNS
• RFC 2181 — aclaraciones, incluyendo sobre CNAME
• RFC 2182 — elección de servidores DNS secundarios
• RFC 8659 — CAA
• RFC 9460 — SVCB y HTTPS
• Cloudflare: CNAME flattening
• AWS Route 53: alias records