Analizador de registros DNS

Los registros DNS (Sistema de Nombres de Dominio) asignan nombres de dominio a direcciones IP y configuran el enrutamiento de correo electrónico. Esta herramienta analiza la salida de archivos de zona de dig o BIND, analiza registros de autenticación de correo (SPF, DMARC, DKIM, BIMI) y advierte sobre configuraciones incorrectas comunes.

Especificaciones

Casos de uso comunes

  • Analizar salida de comandos dig o host para resolución de problemas
  • Auditar la configuración DNS del dominio antes de una migración
  • Verificar la configuración de autenticación de correo (SPF, DMARC, DKIM)
  • Depurar problemas de entregabilidad de correo electrónico
  • Documentar registros DNS del dominio para cumplimiento normativo
  • Verificar registros CAA antes de solicitar certificados SSL

Funcionalidades

  • Analizar salida de archivos de zona BIND/dig
  • Mostrar registros A, AAAA, NS, MX, TXT, CNAME, SOA, SRV, CAA, TLSA
  • Formato de TTL legible para humanos (5m, 2h, 1d)
  • Detección y análisis automático de registros SPF con explicaciones de mecanismos
  • Analizar políticas DMARC y configuración de reportes
  • Análisis de registros DKIM (tipo de clave, selector, validez, modo de prueba)
  • Análisis de registros BIMI (presencia de VMC, validez)
  • Soporte DNSSEC (registros DNSKEY, DS, RRSIG con expiración)
  • Visualización de fijación de certificados TLSA/DANE
  • Validar el conteo de búsquedas DNS de SPF (máximo 10 según RFC 7208)
  • Advertir sobre configuraciones incorrectas de autenticación de correo

Ejemplos

Salida de archivo de zona

Pruébalo →

Salida de dig mostrando varios tipos de registros.

example.com.             300     IN      A       192.0.2.1
example.com.             172800  IN      NS      ns1.example.com.
example.com.             172800  IN      NS      ns2.example.com.
example.com.             300     IN      MX      10 mail.example.com.
example.com.             300     IN      TXT     "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.      300     IN      TXT     "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Registro SPF

Pruébalo →

Un registro SPF que autoriza a Google y Mailgun a enviar correo electrónico.

v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~all

Registro DMARC

Pruébalo →

Una política DMARC estricta con reportes agregados y forenses.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s; pct=100

Consejos

  • Obtener todos los registros con: dig example.com ANY +noall +answer
  • SPF permite máximo 10 búsquedas DNS. Use "include" con moderación.
  • DMARC p=reject es lo más estricto, pero comience con p=none y reportes rua.
  • Los registros CAA restringen qué CAs pueden emitir certificados para su dominio.
  • Los registros TLSA habilitan DANE para la verificación de certificados.

Comprender Analizador de registros DNS

El Sistema de Nombres de Dominio (DNS) es el servicio de directorio de internet, traduciendo nombres de dominio legibles para humanos en direcciones IP y proporcionando otras asignaciones críticas. Los registros DNS se almacenan en archivos de zona en servidores de nombres autoritativos, cada uno con un nombre, tipo, clase, TTL (tiempo de vida) y datos específicos del tipo.

Los tipos de registro más fundamentales manejan la resolución de nombres. Los registros A mapean un dominio a una dirección IPv4, los registros AAAA mapean a IPv6. Los registros CNAME crean alias apuntando un nombre a otro. Los registros NS delegan subdominios a servidores de nombres específicos. Los registros MX dirigen el correo electrónico a servidores de correo con un valor de prioridad. Los registros SOA contienen metadatos de la zona incluyendo el servidor de nombres primario y número de serie.

Los registros TXT transportan datos de autenticación de correo electrónico. Los registros SPF (v=spf1 ...) especifican remitentes de correo autorizados. Los registros DMARC (v=DMARC1; ...) indican a los receptores cómo manejar fallos de SPF/DKIM. Los registros DKIM almacenan claves públicas para la verificación de firmas de correo. La autenticación de correo mal configurada es una causa principal de problemas de entregabilidad.

El valor TTL controla cuánto tiempo los resolvedores almacenan en caché las respuestas. TTLs altos (86400 segundos = 1 día) reducen el tráfico DNS pero hacen que los cambios sean lentos de propagar. TTLs bajos (300 segundos = 5 minutos) permiten actualizaciones rápidas pero aumentan el volumen de consultas. Antes de migraciones, reduzca los TTLs con anticipación para que los valores antiguos expiren rápidamente.

DNS realmente no "propaga" de la manera que el término implica. Cuando un registro cambia, los resolvedores continúan sirviendo el valor antiguo almacenado en caché hasta que su TTL expira, luego obtienen el nuevo valor del servidor autoritativo. Si el TTL era 86400 (24 horas), puede tomar hasta 24 horas para que el cambio sea visible en todas partes. Para acelerar los cambios, reduzca el TTL con anticipación (por ejemplo, a 300 segundos 48 horas antes de la migración), haga la actualización, y luego vuelva a aumentar el TTL.

Un registro A mapea un dominio directamente a una dirección IPv4, mientras que un CNAME crea un alias apuntando a otro nombre de dominio — el resolvedor sigue la cadena hasta el registro A final. Los CNAMEs no se pueden usar en el apex de la zona (dominio desnudo como example.com) porque entran en conflicto con los registros SOA y NS requeridos en el apex. Algunos proveedores de DNS ofrecen tipos de registro propietarios ALIAS o ANAME para evitar esta limitación.

Configurar la autenticación de correo involucra tres registros DNS. Para SPF, agregue un registro TXT con "v=spf1" seguido de los remitentes autorizados. Para DKIM, agregue un registro TXT en un subdominio selector que contenga la clave pública proporcionada por el servicio de correo. Para DMARC, agregue un registro TXT en _dmarc.sudominio.com especificando la política (none, quarantine o reject) y una dirección de reportes. Comenzar con p=none permite monitorear la alineación antes de aplicar. Los fallos de SPF son comúnmente causados por exceder el límite de 10 búsquedas DNS, olvidar autorizar un servicio de envío, usar -all (fallo duro) antes de que todos los remitentes estén verificados, o tener múltiples registros SPF en el mismo dominio — solo se permite un registro v=spf1, y múltiples registros causan un error permanente.

← Volver a todas las herramientas