Saltar al contenido
> 💻 🧠 Código 1001 > 📑 Hojas de Trucos > 🖧 Guía completa y exhaustiva sobre los registros DNS: desde lo básico hasta DNSSEC y la automatización.

🖧 Guía completa y exhaustiva sobre los registros DNS: desde lo básico hasta DNSSEC y la automatización.

DNS (Sistema de Nombres de Dominio) es el sistema fundamental sobre el que se sostiene todo el internet moderno. No es simplemente una «guía telefónica», sino una base de datos compleja y distribuida que traduce nombres legibles por humanos (por ejemplo, google.com) en identificadores técnicos, como direcciones IP, servidores de correo, políticas de seguridad e incluso coordenadas geográficas. Una configuración incorrecta de DNS es una de las causas más frecuentes de indisponibilidad de sitios web, problemas con la entrega de correo y vulnerabilidades de seguridad.

Esta guía combina todos los aspectos de DNS: desde los registros básicos que se usan a diario hasta mecanismos complejos como DNSSEC y DANE. Examinaremos cada tipo de registro, su propósito, sintaxis, ejemplos prácticos, errores comunes, comandos para diagnóstico y plantillas listas para implementación. La información está estructurada para que puedas usar este material como libro de texto, referencia de administrador y lista de verificación para entornos de producción.

In Questo Articolo
  1. 1. Terminología
  2. 2. Desglose detallado de todos los tipos de registros
  3. 3. Recomendaciones prácticas y matices de configuración
  4. 4. Plantillas completas de archivos de zona (estilo BIND)
  5. 5. Configuración paso a paso del dominio de correo (PTR, SPF, DKIM, DMARC)
  6. 6. Comandos para verificación y depuración de DNS
  7. 7. Seguridad y mejores prácticas
  8. 8. Errores comunes y cómo evitarlos
  9. 9. Lista de verificación antes del lanzamiento en producción o migración
  10. 10. Ejemplos adicionales y explicaciones de campos
  11. 11. Escenarios útiles
  12. 12. JSON listo para importar en el panel del proveedor

1. Terminología

Antes de profundizar en los tipos de registros, es crucial entender los términos clave utilizados en DNS. Esto establece una base lingüística común y ayuda a evitar confusiones.

  • DNS (Domain Name System): El Sistema de Nombres de Dominio. Una base de datos distribuida global que traduce nombres de dominio en direcciones IP y otra información relacionada.
  • Nombre de dominio (Domain Name): Una dirección legible por humanos en internet, por ejemplo, example.com. Consiste en etiquetas separadas por puntos.
  • FQDN (Fully Qualified Domain Name): Un nombre de dominio completo que identifica de forma única un nodo en la jerarquía DNS. Siempre termina con un punto que denota la raíz de DNS (por ejemplo, www.example.com.).
  • Zona (Zone): Una unidad administrativa en DNS. Una porción del espacio de nombres administrada por un servidor autoritativo (o un grupo de servidores). Generalmente corresponde a un dominio o subdominio.
  • Archivo de zona (Zone File): Un archivo de texto almacenado en un servidor DNS que contiene todos los registros para una zona específica. Utiliza la sintaxis definida por el estándar BIND.
  • Registro (Resource Record, RR): La unidad básica de datos en DNS. Cada registro tiene un tipo, nombre, valor y TTL.
  • Tipo de registro (Record Type): Define qué información contiene el registro (por ejemplo, A, MX, TXT). Cada tipo corresponde a un código numérico único (por ejemplo, 1 para A, 15 para MX).
  • TTL (Time To Live): La vida útil del registro, especificada en segundos. Determina cuánto tiempo los resolvers y otros servidores DNS pueden almacenar en caché el registro antes de solicitarlo nuevamente al servidor autoritativo.
  • Resolver: Un cliente o servidor DNS que recibe una solicitud de una aplicación (por ejemplo, un navegador) y realiza las consultas necesarias para obtener una respuesta. Puede ser recursivo (realiza la cadena completa de consultas) o no recursivo.
  • Servidor autoritativo (Authoritative Server): Un servidor DNS que almacena los registros originales para una zona específica y es responsable de ellos. Responde a las consultas utilizando datos del archivo de zona.
  • Servidor recursivo (Recursive Server): Un servidor que recibe una solicitud de un cliente y, si no tiene la respuesta en su caché, realiza una cadena de consultas, comenzando desde los servidores raíz, para encontrar el servidor autoritativo y obtener la respuesta.
  • Servidor raíz (Root Server): Uno de los 13 grupos de servidores (denotados por letras de a.root-servers.net. a m.root-servers.net.) que son el punto de partida para resolver cualquier nombre de dominio. Saben dónde se encuentran los servidores para los dominios de nivel superior (TLD).
  • TLD (Top-Level Domain): Un dominio de nivel superior. La última parte de un nombre de dominio (por ejemplo, .com, .org, .ru, .io).
  • Registrador (Registrar): La empresa a través de la cual se registran los nombres de dominio. Gestiona la información de delegación (qué servidores NS sirven al dominio) en la zona padre (por ejemplo, en la zona .com para el dominio example.com).
  • Registrante (Registrant): El propietario del nombre de dominio.
  • Delegación (Delegation): El proceso de transferir el control de un subdominio (o dominio) de la zona padre a la hija. Se logra mediante registros NS en la zona padre.
  • Registro Glue (Glue Record): Un registro A o AAAA publicado por el registrador para un servidor de nombres cuyo nombre de dominio está dentro de la zona delegada. Necesario para romper una dependencia circular.
  • SOA (Start of Authority): Un registro que contiene información administrativa sobre la zona, incluyendo el servidor primario, contacto del administrador y parámetros que controlan la transferencia de zona a servidores secundarios.
  • Número de serie (Serial Number): Un campo en el registro SOA que indica la versión de la zona. Los servidores secundarios lo usan para determinar si se necesita una actualización.
  • Resolución directa (Forward Resolution): El proceso de convertir un nombre de dominio en una dirección IP (por ejemplo, example.com → 192.0.2.1).
  • Resolución inversa (Reverse Resolution): El proceso de convertir una dirección IP en un nombre de dominio (por ejemplo, 192.0.2.1 → example.com). Gestionado a través de zonas in-addr.arpa (para IPv4) y ip6.arpa (para IPv6).
  • Caché: Un almacenamiento temporal para registros DNS en un resolver o servidor DNS para acelerar solicitudes posteriores.
  • Almacenamiento en caché (Caching): El proceso de guardar registros DNS en una caché.
  • Almacenamiento en caché negativo (Negative Caching): Almacenar en caché información de que el registro solicitado no existe.
  • RFC (Request for Comments): Un documento oficial que describe estándares, protocolos y procedimientos en internet. Todos los aspectos principales de DNS se describen en una serie de RFC.
  • BIND (Berkeley Internet Name Domain): La implementación más común de un servidor DNS. La sintaxis de sus archivos de zona se ha convertido en el estándar de facto.
  • MTA (Mail Transfer Agent): Un servidor de correo responsable de transferir correos electrónicos (por ejemplo, Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS): Un mecanismo de verificación donde una dirección IP tiene un registro PTR que se resuelve en un nombre de dominio, y ese nombre de dominio, a su vez, tiene un registro A que apunta de nuevo a la dirección IP original. Crítico para la reputación del servidor de correo.
  • DNSSEC (Domain Name System Security Extensions): Un conjunto de extensiones que agregan firmas criptográficas a los registros DNS para garantizar su autenticidad e integridad.
  • DANE (DNS-based Authentication of Named Entities): Un estándar que permite vincular certificados TLS a nombres DNS mediante registros TLSA. Requiere que DNSSEC esté habilitado.
  • CAA (Certification Authority Authorization): Un mecanismo que permite al propietario de un dominio especificar qué autoridades de certificación (CA) están autorizadas para emitir certificados para él.
  • SPF (Sender Policy Framework): Un mecanismo que permite al propietario de un dominio especificar qué servidores están autorizados a enviar correo en su nombre.
  • DKIM (DomainKeys Identified Mail): Un mecanismo que permite firmar correos electrónicos salientes con una firma digital que el destinatario puede verificar utilizando una clave pública publicada en DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): Una política que define cómo los servidores de correo deben manejar los correos que no pasan las verificaciones SPF o DKIM y configura el envío de informes al propietario del dominio.
  • ALIAS / ANAME: Tipos de registros no estándar ofrecidos por algunos proveedores de DNS. Permiten crear alias para el dominio raíz (apex), lo cual es imposible con un CNAME estándar.
  • CNAME Flattening: Una tecnología utilizada por algunos proveedores de DNS. Cuando se consulta un CNAME para un dominio apex, el servidor resuelve automáticamente la cadena CNAME y devuelve los registros A/AAAA finales al cliente, evitando la violación de RFC.

2. Desglose detallado de todos los tipos de registros

Todos los ejemplos se proporcionan en formato de archivo de zona estilo BIND. Los nombres que terminan con un punto (por ejemplo, example.com.) son FQDN. TTL (Time To Live) se especifica en segundos y determina cuánto tiempo se puede almacenar en caché el registro por los resolvers.

A — Registro de dirección (IPv4)

  • Propósito: Vincula un nombre de dominio a una dirección IPv4 de 32 bits. El registro más básico y frecuentemente utilizado.
  • Formato: nombre TTL IN A dirección-IPv4
  • Ejemplo:
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • Cuándo se usa: Para especificar la dirección IP de un servidor web, API, servidor de juegos o cualquier otro servicio accesible a través de IPv4.
  • Verificación: dig +short example.com A
  • Mejores prácticas:
    • Usar un registro A para el dominio raíz (apex, @) es una práctica estándar y correcta.
    • Elija TTL según la estabilidad de la dirección IP. Para direcciones estables — 3600 (1 hora) o 86400 (1 día). Antes de la migración — reduzca a 300 (5 minutos).

AAAA — Registro de dirección IPv6

  • Propósito: Análogo al registro A, pero para direcciones IPv6 de 128 bits. Críticamente importante para el futuro de internet.
  • Formato: nombre TTL IN AAAA dirección-IPv6
  • Ejemplo:
    example.com. 3600 IN AAAA 2001:db8::1
  • Cuándo se usa: Para garantizar la disponibilidad del servicio a través del protocolo IPv6.
  • Verificación: dig +short example.com AAAA

CNAME — Registro de nombre canónico

  • Propósito: Crea un alias para un nombre de dominio. Cualquier solicitud a un CNAME se convierte automáticamente en una solicitud a su nombre objetivo (canónico).
  • Formato: nombre TTL IN CNAME objetivo.
  • Ejemplo:
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Restricciones importantes:
    • Conflicto de registros: No puede tener un CNAME y cualquier otro registro (A, MX, TXT, etc.) para el mismo nombre. Esto es una violación de RFC.
    • Dominio Apex: El estándar RFC prohíbe usar CNAME para el dominio raíz (por ejemplo, example.com.) porque ya contiene registros NS y SOA. Para resolver esto, los proveedores de DNS (Cloudflare, AWS Route 53) ofrecen extensiones no estándar: ALIAS o ANAME, que resuelven el alias en registros A/AAAA sobre la marcha.
  • Aplicación práctica: Conectar un CDN (hacer que www sea un CNAME a la dirección del CDN), usar plataformas SaaS (blog, tienda).
  • Verificación: dig +short www.example.com CNAME

MX — Registro de intercambio de correo

  • Propósito: Especifica los servidores que aceptan correo entrante para el dominio. El registro contiene una prioridad: cuanto menor sea el número, mayor será la prioridad.
  • Formato: nombre TTL IN MX prioridad servidor_de_correo.
  • Ejemplo:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • El correo se enviará primero a mail1.example.com.. Si no está disponible, el MTA (Agente de Transferencia de Correo) intentará mail2.example.com..
  • Requisitos clave:
    • El servidor de correo (mail1.example.com.) debe tener su propio registro A o AAAA.
    • Un registro PTR debe configurarse para la dirección IP del servidor de correo, y debe coincidir con el nombre del servidor especificado en el MX. Esto es crítico para la reputación del servidor y la entrega del correo.
  • Verificación: dig +short example.com MX

TXT — Registro de texto

  • Propósito: Almacena datos de texto arbitrarios. Ampliamente utilizado para políticas de seguridad de correo electrónico (SPF, DKIM, DMARC), verificación de propiedad de dominio (Google, Microsoft, Yandex) y otros fines.
  • Formato: nombre TTL IN TXT "texto"
  • Ejemplos:
    • SPF (Sender Policy Framework): Define qué servidores están autorizados a enviar correo en nombre del dominio. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 — permite toda la subred.
      • include:_spf.google.com — incluye reglas de la zona de Google (para Gmail).
      • ~all — «fallo suave» para todos los demás (softfail). -all — fallo estricto (fail).
    • DKIM (DomainKeys Identified Mail): Publica la clave pública para verificar la firma digital agregada a los correos salientes. Generalmente se crea para un subdominio como selector._domainkey.dominio. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 — versión.
      • k=rsa — tipo de clave.
      • p=... — la clave pública en sí en formato base64.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): Establece la política para manejar correos que no pasan las verificaciones SPF o DKIM y configura el envío de informes. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject — rechazar correos que no pasan la verificación.
      • rua=mailto:... — dirección para informes agregados.
      • ruf=mailto:... — dirección para informes forenses (fallas específicas).
      • pct=100 — aplicar política al 100% de los correos.
    • Verificación: example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Notas:
    • Si una cadena de texto es más larga de 255 bytes, se puede dividir en varias partes en el archivo de zona, con cada parte encerrada entre comillas. El servidor DNS las concatenará automáticamente.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Verificación: dig +short example.com TXT

NS — Registro de servidor de nombres

  • Propósito: Especifica los servidores DNS que son autoritativos para la zona. Estos registros son la base para delegar la gestión del dominio.
  • Formato: nombre TTL IN NS nombre_del_servidor.
  • Ejemplo:
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Puntos importantes:
    • Los registros NS en la zona deben coincidir exactamente con los servidores de nombres especificados con el registrador de dominio.
    • Registros Glue: Si el servidor de nombres (por ejemplo, ns1.example.com.) se encuentra dentro de la misma zona que sirve (example.com.), surge una dependencia circular. Para romperla, agregue registros «glue» — registros A o AAAA para estos servidores de nombres — con el registrador.
  • Verificación: dig +short example.com NS

SOA — Registro de inicio de autoridad

  • Propósito: El registro administrativo principal de una zona DNS. Contiene información sobre el servidor principal, el administrador y parámetros que controlan la sincronización entre el servidor principal y los secundarios.
  • Formato:
    nombre TTL IN SOA servidor_primario. email_administrador. ( número_de_serie ; Serial intervalo_de_actualización ; Refresh intervalo_de_reintento ; Retry tiempo_de_vencimiento ; Expire ttl_mínimo ) ; Minimum TTL
  • Ejemplo:
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 horas) 3600 ; Retry (1 hora) 1209600 ; Expire (14 días) 86400 ) ; Minimum TTL (1 día)
  • Explicaciones de campos:
    • Serial: Versión de la zona. Es crucialmente importante incrementar este número con cada cambio en la zona. Los servidores secundarios comparan su Serial con el Serial en el servidor primario y, si es menor, solicitan una actualización. Formato recomendado: YYYYMMDDNN (año, mes, día, número de revisión del día).
    • Refresh: Intervalo (en segundos) después del cual los servidores secundarios deben verificar el servidor primario en busca de actualizaciones.
    • Retry: Intervalo después del cual un servidor secundario debe reintentar si falla el primer intento de actualización.
    • Expire: Tiempo (en segundos) después del cual un servidor secundario dejará de responder a consultas si no puede contactar al servidor primario. La zona se considera «caducada».
    • Minimum TTL: Originalmente establecía el TTL mínimo para todos los registros en la zona. Ahora a menudo se usa como el TTL para el almacenamiento en caché negativo (cuánto tiempo almacenar en caché una respuesta de «registro no encontrado»).
  • Verificación: dig +short example.com SOA

PTR — Registro de puntero (DNS inverso)

  • Propósito: Proporciona resolución inversa — convierte una dirección IP en un nombre de dominio. Gestionado por el propietario de la dirección IP (ISP, proveedor de hosting), no por el propietario del dominio.
  • Formato para IPv4: La dirección IP se escribe en orden inverso, y se agrega el sufijo .in-addr.arpa..
    • IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
  • Formato para IPv6: Cada parte de 4 bits (nibble) de la dirección se escribe en orden inverso, y se agrega el sufijo .ip6.arpa..
    • IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Ejemplo (IPv4):
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Significado práctico: Críticamente importante para los servidores de correo. La mayoría de los sistemas de correo verifican que el registro PTR para la dirección IP del remitente coincida con el nombre que el servidor presenta en el comando HELO/EHLO. Una discrepancia es una razón común para que los correos sean marcados como spam.
  • Verificación: dig -x 192.0.2.5 +short o host 192.0.2.5

SRV — Registro de servicio

  • Propósito: Especifica la ubicación de los servidores para servicios específicos, incluyendo protocolo y puerto. Permite a los clientes encontrar automáticamente el servidor necesario.
  • Formato de nombre:_servicio._protocolo.dominio.
    • Servicio: sip, xmpp-server, _minecraft, etc.
    • Protocolo: tcp, udp.
  • Formato de registro: nombre TTL IN SRV prioridad peso puerto objetivo.
  • Ejemplo:
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Explicaciones de campos:
    • Priority (Prioridad): Cuanto menor sea el número, mayor será la prioridad. El cliente intentará primero conectarse al servidor con la prioridad más baja.
    • Weight (Peso): Se utiliza para el balanceo de carga entre servidores con la misma prioridad. La probabilidad de seleccionar un servidor es proporcional a su peso. Si todos los pesos son iguales, la selección es aleatoria.
    • Port (Puerto): El puerto en el que se ejecuta el servicio.
    • Target (Objetivo): El FQDN del servidor al que se debe dirigir la solicitud. Este servidor debe tener un registro A o AAAA.
  • Aplicación: VoIP (SIP), mensajería instantánea (XMPP), juegos (Minecraft), directorios (LDAP).
  • Verificación: dig +short _sip._tcp.example.com SRV

CAA — Autorización de autoridad de certificación

  • Propósito: Permite al propietario del dominio especificar qué autoridades de certificación (CA) están autorizadas a emitir certificados SSL/TLS para este dominio. Este es un mecanismo de seguridad importante para prevenir la emisión no autorizada de certificados.
  • Formato: nombre TTL IN CAA flags etiqueta valor
  • Ejemplo:
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Explicaciones:
    • Flags: Generalmente 0. La bandera 128 (crítica) significa que una CA que no entiende esta etiqueta debe rechazar emitir el certificado.
    • Tags:
      • issue: Permite a la CA especificada emitir certificados. Un valor vacío (;) prohíbe la emisión por parte de cualquiera.
      • issuewild: Permite la emisión de certificados wildcard (*.example.com).
      • iodef: URL (generalmente mailto: o http(s):) para enviar informes sobre intentos de violar la política CAA.
  • Verificación: dig +short example.com CAA

NAPTR — Registro de puntero de autoridad de nombres

  • Propósito: Se utiliza para reglas complejas de reescritura de nombres y URI. Más a menudo se aplica en sistemas de telecomunicaciones (ENUM para convertir números de teléfono en URI SIP) y para descubrimiento de servicios dinámico.
  • Formato: nombre TTL IN NAPTR orden preferencia banderas servicio expresión_regular reemplazo.
  • Ejemplo (simplificado para ENUM):
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Explicaciones:
    • Order (Orden): Procesado de menor a mayor.
    • Preference (Preferencia): Análogo al weight en SRV para registros con el mismo order.
    • Flags: U significa que el resultado es un URI (por ejemplo, sip:).
    • Service: Tipo de servicio (por ejemplo, E2U+sip — conversión a URI SIP).
    • Regexp: Expresión regular para transformar la cadena de entrada.
    • Replacement: Alternativa a la expresión regular (generalmente vacía si se usa regexp).
  • Aplicación: Escenarios de enrutamiento complejos en VoIP, ENUM.

TLSA — Registro de asociación de certificados TLSA (DANE)

  • Propósito: Vincula un certificado TLS (o parte de él) a un nombre DNS mediante un registro DNS. Esto es parte del estándar DANE (Autenticación Basada en DNS de Entidades Nombradas). Requiere que DNSSEC esté habilitado para garantizar la confianza; de lo contrario, el registro se puede falsificar.
  • Formato de nombre: _puerto._protocolo.nombre.
  • Formato de registro: nombre TTL IN TLSA uso selector tipo_de_coincidencia datos
  • Ejemplo:
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Explicaciones de campos:
    • Usage (Uso):
      • 3 (DANE-EE): Certificado de entidad final. El más común.
      • 1 (PKIX-EE): Certificado de entidad final, debe estar firmado por una CA de confianza.
      • 2 (DANE-TA): Certificado de autoridad de certificación de confianza.
      • 0 (PKIX-TA): Certificado de CA, debe estar en la cadena de confianza.
    • Selector (Selector):
      • 0: Certificado completo.
      • 1: Solo la clave pública del certificado.
    • Matching Type (Tipo de coincidencia):
      • 0: Datos exactos (no se usa).
      • 1: Hash SHA-256.
      • 2: Hash SHA-512.
    • Data: Hash del certificado o su clave pública en formato hex.
  • Aplicación: Mejora la seguridad de TLS, especialmente en entornos donde no se puede confiar en las CA públicas.
  • Verificación: dig +short _443._tcp.www.example.com. TLSA

Registros DNSSEC (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (Extensiones de Seguridad del Sistema de Nombres de Dominio) es un conjunto de extensiones que agregan firmas criptográficas a los registros DNS para proteger contra la falsificación (spoofing) y ataques de envenenamiento de caché.

  • Principio general: La zona se firma con una clave privada. La clave pública se publica en un registro DNSKEY. Para crear una cadena de confianza, el hash de esta clave (DS registro) se publica en la zona padre (por ejemplo, para example.com — en la zona .com). Los clientes que admiten DNSSEC pueden verificar la firma (RRSIG) de cada registro utilizando la clave pública y asegurarse de su autenticidad.
  • DNSKEY: La clave pública de la zona.
    • Ejemplo:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 — banderas (257 = KSK, 256 = ZSK).
      • 3 — protocolo (siempre 3).
      • 13 — algoritmo (13 = ECDSA/SHA256).
      • Último campo — clave en base64.
  • DS (Delegation Signer): Hash de la clave pública (DNSKEY) de la zona hija, publicado en la zona padre para crear una cadena de confianza.
    • Ejemplo:example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 — Key Tag (identificador de clave).
      • 13 — Algoritmo.
      • 2 — Tipo de resumen (SHA-256).
      • Último campo — hash en hex.
  • RRSIG (Firma de registro de recurso): Firma digital para un conjunto de registros DNS.
    • Ejemplo (firma para registro A):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A — tipo de registros firmados.
      • 13 — algoritmo.
      • 2 — número de etiquetas en el nombre.
      • 3600 — TTL original.
      • 20251001000000 — tiempo de expiración de la firma.
      • 20250901000000 — tiempo de inicio de la firma.
      • 54517 — Key Tag de la clave de firma.
      • example.com. — nombre del firmante.
      • Último campo — firma en base64.
  • NSEC / NSEC3: Se utilizan para autenticar respuestas negativas (prueba de que un registro con tal nombre o tipo no existe). NSEC3 además aplica hash a los nombres para proteger contra «caminatas de zona».
  • Habilitar DNSSEC: Este es un proceso separado y complejo:
    1. Genere pares de claves (KSK y ZSK) en el servidor DNS.
    2. Publique registros DNSKEY en la zona.
    3. Genere un registro DS a partir del KSK.
    4. Publique el registro DS con el registrador de dominio (en la zona padre).
    5. Habilite la firma de zona en el servidor DNS (generación automática de RRSIG, NSEC/NSEC3).
    6. Pruebe usando dig +dnssec y herramientas en línea (por ejemplo, Verisign DNSSEC Debugger).
  • Verificación:
    • dig +dnssec example.com A (mostrará RRSIG para el registro A si DNSSEC está habilitado y funcionando).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP — Huella digital de clave pública SSH

  • Propósito: Publica el hash (huella digital) de la clave SSH del host en DNS. Los clientes SSH pueden usar este registro para verificar automáticamente la autenticidad del servidor en la primera conexión, evitando ataques de «hombre en el medio» (MITM). Se recomienda usar con DNSSEC para garantizar la autenticidad del registro.
  • Formato: nombre TTL IN SSHFP algoritmo tipo_de_resumen huella_digital
  • Ejemplo:
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Explicaciones:
    • Algorithm (Algoritmo):
      • 1 — RSA
      • 2 — DSA
      • 3 — ECDSA
      • 4 — ED25519
    • Digest Type (Tipo de resumen):
      • 1 — SHA-1
      • 2 — SHA-256
    • Fingerprint: Hash de la clave pública en formato hex.
  • Generación: En el servidor, puede generar el registro con el comando: ssh-keygen -r example.com
  • Verificación: dig +short example.com SSHFP

Registros raros y de servicio

  • HINFO (Información del host): Almacena información sobre el tipo de CPU y sistema operativo del host. No se recomienda su uso ya que revela información potencialmente sensible del sistema.
    • Ejemplo: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Ubicación): Almacena las coordenadas geográficas (latitud, longitud, altitud) del host.
    • Ejemplo: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Persona responsable): Especifica la persona de contacto responsable de la zona. El correo electrónico se especifica en formato de nombre de host (punto en lugar de @).
    • Ejemplo: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (obsoleto): Anteriormente existía como un tipo de registro separado pero ahora está completamente reemplazado por TXT. No debe usarse.
    • Ejemplo (no usar): example.com. IN SPF "v=spf1 ..."

3. Recomendaciones prácticas y matices de configuración

  • Gestión de TTL:
    • Valor estándar: 3600 segundos (1 hora) — un buen equilibrio entre rendimiento (caché) y flexibilidad.
    • Antes de la migración: Reduzca el TTL para los registros relevantes (por ejemplo, A/AAAA para su sitio web) a 300 segundos (5 minutos) 24-72 horas antes del cambio planeado. Esto reduce el tiempo para que los cambios se propaguen.
    • Después de la migración: Una vez que los cambios se hayan estabilizado, aumente el TTL de nuevo a un valor óptimo (por ejemplo, 3600 o 86400) para reducir la carga en los servidores DNS.
  • SOA Serial:
    • Siempre incremente el número de serie después de cada cambio en la zona. Si no lo hace, los servidores secundarios no se enterarán de las actualizaciones.
    • Formato recomendado: YYYYMMDDNN (por ejemplo, 2024051701). Esto es claro y permite un seguimiento fácil de cuándo se realizó el último cambio.
  • CNAME en Apex (Dominio raíz):
    • Problema: El estándar RFC prohíbe CNAME en el dominio apex (por ejemplo, example.com.) porque entra en conflicto con otros registros obligatorios (NS, SOA).
    • Solución: Utilice funciones proporcionadas por su proveedor de DNS:
      • ALIAS/ANAME: Tipos de registros no estándar que se comportan como CNAME pero se resuelven por el servidor DNS del proveedor en registros A/AAAA para la respuesta del cliente. Esto permite usar alias en el apex.
      • CNAME Flattening: Una tecnología (por ejemplo, en Cloudflare) donde un CNAME en el apex se «aplana» automáticamente — el servidor DNS devuelve los registros A/AAAA del host objetivo en lugar del CNAME.
  • Registros Glue:
    • Cuándo se necesitan: Si sus servidores de nombres (por ejemplo, ns1.example.com.) se encuentran dentro de la misma zona que sirven (example.com.).
    • Qué hacer: Encuentre la sección de configuración de registros glue con su registrador de dominio y agregue registros A (y/o AAAA) para sus servidores de nombres. Esto rompe la dependencia circular.
  • Configuración de PTR para correo:
    • Requisito: La dirección IP de su servidor de correo debe tener un registro PTR que se resuelva en su nombre de dominio completamente calificado (FQDN, por ejemplo, mail.example.com.).
    • Consistencia: El nombre que el servidor de correo envía en el comando HELO/EHLO debe coincidir con el nombre del registro PTR, y ese nombre, a su vez, debe tener un registro A que apunte de nuevo a la misma dirección IP. Esto se llama «Forward-Confirmed Reverse DNS» (FCrDNS) y es crítico para la reputación.
    • Dónde configurar: Con su proveedor de hosting o propietario de la dirección IP, no en la zona DNS de su dominio.
  • División de registros TXT largos:
    • Si una cadena en un registro TXT excede los 255 bytes, debe dividirse en varias partes en el archivo de zona. Cada parte se encierra entre comillas, y el servidor DNS las concatena automáticamente.
    • Ejemplo:
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Plantillas completas de archivos de zona (estilo BIND)

A continuación se muestran plantillas listas para tres escenarios comunes. Reemplace example.com, example.net, direcciones IP y claves con sus propios valores.

a) Sitio web simple (estático, sin correo)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 hours)
        3600       ; retry (1 hour)
        1209600    ; expire (14 days)
        86400 )    ; minimum TTL (1 day)

; Authoritative Name Servers
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Web Server (IPv4 and IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; WWW subdomain (alias to apex)
www     IN CNAME @

; Security: Restrict Certificate Authorities
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Sitio web + servidor de correo propio

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Mail Section ---
; A record for the mail server
mail    IN A    192.0.2.20

; MX record pointing to the mail server
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
; SPF: Allow mail server IP and Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Public key for 'default' selector
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Policy to quarantine failures and send reports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"

c) Sitio web + CDN + Correo + DNSSEC (ejemplo complejo)

$TTL 300 ; Lower TTL for flexibility with CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (also used for negative caching)

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section (with CDN) ---
; Apex domain: Use ALIAS/ANAME (provider-specific) to point to origin or CDN edge
; If your provider supports ALIAS:
; @     IN ALIAS origin.examplehost.net.
; If using CNAME flattening for apex (e.g., Cloudflare):
@       IN A    192.0.2.10 ; Temporary or fallback IP, often managed by provider

; WWW subdomain: CNAME to CDN provider
www     IN CNAME cdn-provider.example.net.

; --- Mail Section ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Example keys - REPLACE WITH YOURS) ---
; DNSKEY records (usually auto-generated by DNS server when signing is enabled)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; RRSIG records are automatically generated by the DNS server during signing and are not manually added to the zone file.
; NSEC/NSEC3 records are also automatically generated.

; --- Additional Services (Example) ---
; SRV record for SIP service
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Configuración paso a paso del dominio de correo (PTR, SPF, DKIM, DMARC)

La configuración del correo es una tarea compleja. Siga estos pasos para garantizar la máxima entregabilidad y protección contra el spam.

Paso 1: Configure A/AAAA para el servidor de correo
Asegúrese de que su servidor de correo tenga un registro A (y preferiblemente AAAA).

mail.example.com. 3600 IN A 192.0.2.20

Paso 2: Configure registros MX
Especifique que el correo para example.com debe entregarse a mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Paso 3: Configure PTR (DNS inverso)
Este es el paso más importante y a menudo pasado por alto. Comuníquese con su proveedor de hosting o propietario de la dirección IP (192.0.2.20) y solicite un registro PTR que apunte a mail.example.com..

  • Verificación: dig -x 192.0.2.20 +short debería devolver mail.example.com..

Paso 4: Configure SPF (a través de TXT)
Defina qué servidores están autorizados a enviar correo en nombre de example.com. Incluya su servidor y cualquier servicio de terceros (Gmail, SendGrid, etc.).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Comience con ~all (fallo suave) para pruebas, luego pase a -all (fallo estricto).

Paso 5: Configure DKIM

  1. Genere un par de claves (privada y pública) en su servidor de correo (MTA). Elija un «selector» (por ejemplo, default, 202405).
  2. Configure el MTA para firmar los correos salientes utilizando la clave privada y el selector elegido.
  3. Publique la clave pública en DNS como un registro TXT para el subdominio selector._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Paso 6: Configure DMARC
Defina la política para manejar los correos que no pasan las verificaciones SPF/DKIM y configure el envío de informes.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Estrategia de implementación:
    1. Comience con p=none — los correos no se bloquean, solo recibe informes.
    2. Analice los informes, corrija errores en SPF/DKIM.
    3. Pase a p=quarantine — los correos sospechosos van al spam.
    4. Pase a p=reject — los correos sospechosos se rechazan.

Consejos adicionales:

  • Asegúrese de que el nombre que su servidor de correo envía en el comando HELO/EHLO coincida con el nombre del registro PTR (mail.example.com.).
  • Utilice herramientas en línea para verificar su configuración: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Comandos para verificación y depuración de DNS

Las herramientas de línea de comandos son indispensables para los administradores.

  • dig (Domain Information Groper) — la herramienta más potente y recomendada.
    • Consultas básicas:
      • dig +short example.com A — obtener solo la dirección IPv4.
      • dig +short example.com AAAA — obtener solo la dirección IPv6.
      • dig +short example.com MX — obtener registros MX.
      • dig +short example.com TXT — obtener registros TXT (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME — obtener CNAME.
      • dig +short _sip._tcp.example.com SRV — obtener registro SRV.
    • DNS inverso:
      • dig -x 192.0.2.1 +short — obtener PTR para IP.
    • Trazado de delegación:
      • dig +trace example.com — muestra toda la ruta desde los servidores raíz hasta los servidores autoritativos de su zona. Ideal para diagnosticar problemas de delegación.
    • Consulta a servidor específico:
      • dig @ns1.example.net example.com SOA — solicitar registro SOA a un servidor de nombres específico.
    • Verificación de DNSSEC:
      • dig +dnssec example.com A — realizar una consulta con la bandera DO (DNSSEC OK) y mostrar registros RRSIG si existen.
      • dig +short example.com DNSKEY — obtener registros DNSKEY.
      • dig +short example.com DS — obtener registro DS (de la zona padre).
    • Verificación de TLSA (DANE):
      • dig +short _443._tcp.www.example.com. TLSA
    • Verificación de SSHFP:
      • dig +short example.com SSHFP
  • nslookup — herramienta antigua pero aún encontrada.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (para PTR)
  • host — simple y conveniente para consultas básicas.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (para PTR)
    • host -t sshfp example.com

7. Seguridad y mejores prácticas

  • DNSSEC: Habilite DNSSEC para dominios críticos. Esto protege a sus usuarios de respuestas DNS falsas. Comience con un dominio de prueba para dominar el procedimiento (generación de claves, publicación de DS con el registrador). Utilice validadores en línea para verificar.
  • CAA: Configure siempre registros CAA. Esta es una forma simple y efectiva de evitar la emisión no autorizada de certificados para su dominio. Especifique solo las CA que utiliza (por ejemplo, letsencrypt.org).
  • Gestión de claves DKIM: Genere regularmente (por ejemplo, anualmente) nuevos pares de claves DKIM. Publique la nueva clave pública en DNS, configure el MTA para usar el nuevo selector y, después de algunas semanas (asegurándose de que todos los correos antiguos firmados con la clave anterior se hayan procesado), elimine el registro TXT anterior.
  • Privacidad: No publique registros HINFO ya que revelan información sobre hardware y software que podría ser útil para atacantes.
  • Consultas ANY: Muchos resolvers DNS públicos (por ejemplo, Google Public DNS, Cloudflare) ya no procesan consultas ANY debido a su uso en ataques DDoS. No confíe en ellas.

8. Errores comunes y cómo evitarlos

  1. CNAME entra en conflicto con otros registros: No puede tener un CNAME y, por ejemplo, un A o MX para el mismo nombre. Solución: Revise la estructura de su zona. Use registros A o ALIAS/ANAME para apex.
  2. Falta de PTR para el servidor de correo: Esta es la razón principal por la que el correo termina en spam. Solución: Configure siempre PTR con su proveedor de hosting.
  3. Número de serie SOA sin cambios: Si no incrementa el número de serie, los servidores secundarios no se enterarán de las actualizaciones. Solución: Incremente siempre Serial después de cualquier cambio en la zona. Automatice este proceso si es posible.
  4. Formato incorrecto de registros TXT largos: Si una cadena es más larga de 255 bytes y no se divide en partes, puede truncarse o causar un error. Solución: Divida siempre las cadenas largas en registros TXT, encerrando cada parte entre comillas.
  5. DS incorrecto al habilitar DNSSEC: Si el registro DS publicado con el registrador no coincide con su DNSKEY, la zona se volverá «no confiable», y los clientes con DNSSEC habilitado no podrán obtener registros de ella. Solución: Siga cuidadosamente las instrucciones de su servidor DNS y registrador. Verifique dos veces los hashes.
  6. TTL alto antes de la migración: Si el TTL es alto (por ejemplo, 86400), después de cambiar la dirección IP, los usuarios llegarán a la dirección antigua durante un día. Solución: Reduzca siempre el TTL uno o dos días antes de una migración planeada.
  7. CNAME en el dominio apex: El uso directo de CNAME para example.com. viola RFC y puede causar un comportamiento impredecible. Solución: Use ALIAS/ANAME o CNAME flattening proporcionado por su proveedor de DNS.

9. Lista de verificación antes del lanzamiento en producción o migración

Use esta lista para verificaciones finales antes de lanzar o mover un sitio/servicio.

  • [ ] Registros básicos: A/AAAA para todos los hosts clave (web, correo) están configurados y apuntan a las direcciones IP correctas.
  • [ ] Correo: Los registros MX están configurados y apuntan a hosts con registros A/AAAA.
  • [ ] DNS inverso: Los registros PTR para todas las direcciones IP de los servidores de correo están configurados y son correctos (verificado mediante dig -x).
  • [ ] SPF: El registro TXT SPF está configurado, incluye todas las fuentes permitidas y tiene el mecanismo de terminación correcto (-all o ~all).
  • [ ] DKIM: La clave pública está publicada en DNS, el MTA está configurado para firmar correos. La firma se verifica en un correo de prueba.
  • [ ] DMARC: El registro TXT DMARC está publicado. Para nuevos despliegues, se recomienda comenzar con p=none.
  • [ ] Servidores de nombres: Los registros NS en la zona coinciden con los servidores especificados con el registrador. Los registros glue están configurados si es necesario.
  • [ ] Número de serie SOA: El número de serie se ha incrementado después de todos los cambios recientes.
  • [ ] CAA: Los registros CAA están configurados para restringir la emisión de certificados.
  • [ ] TTL: El TTL se redujo con anticipación (si se planeó una migración).
  • [ ] Verificación: Se realizaron verificaciones usando dig +trace, dig MX, dig TXT y herramientas en línea (por ejemplo, MXToolbox).
  • [ ] DNSSEC (si está habilitado): El registro DS se agregó correctamente con el registrador, las verificaciones de DNSSEC pasan con éxito.
  • [ ] Copia de seguridad: La exportación de la zona actual está guardada.
  • [ ] Plan de reversión: Los pasos para revertir los cambios en caso de falla están claramente escritos.
  • [ ] Monitoreo: Los sistemas de monitoreo están configurados para rastrear la disponibilidad de los servidores DNS y los cambios en la zona.

10. Ejemplos adicionales y explicaciones de campos

  • SRV — Profundización:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • El cliente primero contactará a los servidores con prioridad 5 (xmpp1 y xmpp2).
    • Entre xmpp1 y xmpp2, la selección será proporcional a su peso: xmpp1 tiene un 40% de probabilidad (20/(20+30)), xmpp2 — 60% (30/(20+30)).
    • El servidor backup.example.com. (prioridad 10) solo se usará si ambos servidores con prioridad 5 están no disponibles.
  • TLSA — Decodificación de ejemplo:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE): El cliente debe usar este certificado exacto (o su clave pública), independientemente de la cadena de confianza de la CA.
    • 1 (Selector): El registro almacena el hash no de todo el certificado, sino solo de su clave pública. Esto es más conveniente porque al reemitir un certificado con la misma clave, no necesita cambiar el registro TLSA.
    • 1 (Tipo de coincidencia): Se usa hash SHA-256.
  • SSHFP — Decodificación de ejemplo:
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4: Algoritmo — ED25519 (moderno y seguro).
    • 2: Tipo de resumen — SHA-256.
    • 356a19...28ab: Hash SHA-256 de la clave pública ED25519.

11. Escenarios útiles

  • Conectar un sitio web a un CDN:
    1. Generalmente, el proveedor de CDN le pide que haga un CNAME para un subdominio (por ejemplo, www) a su dirección (por ejemplo, example.cdnprovider.com).
    2. Si desea usar el CDN para el dominio raíz (example.com), use la función ALIAS/ANAME o CNAME flattening de su proveedor de DNS.
    3. Asegúrese de que el CDN esté correctamente configurado para trabajar con su certificado SSL (a menudo el CDN se encarga de la terminación SSL). Tener en cuenta los registros CAA es importante en este caso.
  • Mover un host (migración):
    1. 48-72 horas antes de la migración: Reduzca el TTL para los registros A/AAAA de su sitio a 300 segundos.
    2. Espere: Espere a que el TTL anterior se «propague» (espere un período igual al TTL anterior, por ejemplo, 3600 segundos).
    3. En el día de la migración: Cambie los registros A/AAAA para que apunten a las nuevas direcciones IP.
    4. Verificación: Use dig +short example.com A con diferentes DNS públicos (Google 8.8.8.8, Cloudflare 1.1.1.1) para verificar la propagación de los cambios.
    5. Después de la estabilización (después de 24-48 horas): Aumente el TTL de nuevo a un valor óptimo (por ejemplo, 3600).

12. JSON listo para importar en el panel del proveedor

A continuación se muestra una plantilla JSON extendida que contiene casi todos los tipos de registros cubiertos en esta guía. Este formato es generalizado y puede requerir adaptación a la API específica de su proveedor de DNS (Cloudflare, AWS Route 53, DigitalOcean, etc.).

{
  "zone": "example.com",
  "records": [
    {
      "type": "A",
      "name": "@",
      "value": "192.0.2.10",
      "ttl": 3600
    },
    {
      "type": "AAAA",
      "name": "@",
      "value": "2001:db8::10",
      "ttl": 3600
    },
    {
      "type": "CNAME",
      "name": "www",
      "value": "example.com.",
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "mail.example.com.",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "backup-mail.example.com.",
      "priority": 20,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "value": "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "default._domainkey",
      "value": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQA...",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "value": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns1.example.net.",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns2.example.net.",
      "ttl": 3600
    },
    {
      "type": "SOA",
      "name": "@",
      "primary_ns": "ns1.example.net.",
      "admin_email": "admin.example.com.",
      "serial": 2025092201,
      "refresh": 7200,
      "retry": 3600,
      "expire": 1209600,
      "minimum": 86400,
      "ttl": 3600
    },
    {
      "type": "PTR",
      "name": "20.2.0.192.in-addr.arpa.",
      "value": "mail.example.com.",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "target": "sipserver.example.com.",
      "port": 5060,
      "priority": 10,
      "weight": 60,
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "letsencrypt.org",
      "flags": 0,
      "tag": "issue",
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "mailto:security@example.com",
      "flags": 0,
      "tag": "iodef",
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp.www",
      "usage": 3,
      "selector": 1,
      "matching_type": 1,
      "value": "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971",
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "algorithm": 4,
      "digest_type": 2,
      "value": "356a192b7913b04c54574d18c28d46e6395428ab",
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "server1",
      "cpu": "Intel Xeon",
      "os": "Ubuntu 22.04 LTS",
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "latitude": "55.7558 N",
      "longitude": "37.6176 E",
      "altitude": 150,
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "@",
      "mbox": "admin.example.com.",
      "txt": "Technical Support",
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "4.3.2.1.5.5.5.1.e164.arpa.",
      "order": 100,
      "preference": 10,
      "flags": "U",
      "service": "E2U+sip",
      "regexp": "!^.*$!sip:info@example.com!",
      "replacement": ".",
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "key_tag": 54517,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "84C84478D00A57973FC5D3E32F7E2BF539FB697D2660874C6D33A3313872D34F",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 257,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAbOv...QAB",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 256,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAa3d...9QAB",
      "ttl": 3600
    }
  ]
}


Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": "<hex-of-cert-hash>"
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": "<hex-digest>"
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": "<base64-key>"
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": "<base64-signature>"
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 <hex-of-cert-hash>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U "" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 <hex-digest>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 <base64-key>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com <base64-signature>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}

Full support for all record types: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL and priorities are already set and can be adapted as needed. Uses ResourceRecords for each record, as required by AWS.
Direct import via AWS CLI with the command:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json


DNS es un sistema poderoso y flexible, y el conocimiento de él es críticamente importante para cualquiera que gestione proyectos web, sistemas de correo o infraestructura de red. Esta guía cubre todos los aspectos — desde registros A simples hasta mecanismos de seguridad complejos como DNSSEC y DANE.

Conclusiones clave:

  • Planifique cambios: Siempre reduzca el TTL antes de la migración.
  • Pruebe: Use dig, nslookup y herramientas en línea para verificar cada configuración.
  • Seguridad primero: Configure SPF, DKIM, DMARC para correo. Habilite CAA para controlar certificados. Considere usar DNSSEC para dominios críticos.
  • Documente: Mantenga listas de verificación y guarde copias de seguridad de zonas.

Este material está diseñado para ser su referencia universal. Guárdelo, y le ayudará a resolver cualquier tarea relacionada con DNS.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *