Ir al contenido principal

Búsqueda registro SOA (Start of Authority)

Analice los metadatos y la sincronización de su zona DNS

¿Problemas de sincronización DNS? Verifique el registro SOA para comprender los parámetros de su zona y diagnosticar problemas de replicación.

En modo de traza iterativa, se ignora el resolvedor.
Consulta varios resolvedores públicos para comparar las respuestas.

Metadatos de zona

Consulte el servidor primario, el contacto administrativo y el número de serie que identifica la versión de su zona.

Multi-resolutor

Compare las respuestas de Google, Cloudflare y Quad9 para detectar problemas de propagación del serial.

Parámetros de sincronización

Analice los valores refresh, retry y expire que controlan la sincronización entre servidores primario y secundarios.

TTL y caché negativo

Verifique el minimum TTL que define la duración de caché de las respuestas negativas (NXDOMAIN).

Gratuito e ilimitado

Pruebe tantos dominios como necesite. Sin registro requerido.

¿Cómo usar correctamente las diferentes opciones del motor de búsqueda DNS?

¿Qué es la traza iterativa?

La traza ejecuta la resolución paso a paso. El resolvedor consulta primero a los servidores raíz, luego a los del TLD (.com, .fr, .eu) y finalmente a los servidores autoritativos de la zona objetivo. En cada etapa la página muestra el servidor consultado, la respuesta, el RCODE y la latencia.

  1. 1. Raíz

    Descubrimiento de los servidores del TLD para el nombre solicitado.

  2. 2. TLD

    Referencia a los NS de la zona (delegación).

  3. 3. Autoritativos

    Respuesta final (o error) con TTL y latencia.

¿Para qué sirve?

  • Comparar respuestas según los resolvedores y las regiones
  • Detectar un caché caliente, un TTL demasiado largo o una delegación incompleta
  • Explicar una diferencia de latencia o un RCODE inesperado

Truco: deja la traza desactivada para las comprobaciones rápidas; actívala cuando investigues o prepares un ticket/post-mortem.

¿Qué es la traza clásica?

La traza clásica consulta únicamente el resolvedor seleccionado (UDP o DoH) y muestra la respuesta tal como se percibe desde ese punto de la red. Obtienes el RCODE, las secciones de la respuesta y la latencia del tramo cliente → resolvedor.

  1. 1. Resolvedor elegido

    Utiliza el preset o la configuración personalizada para lanzar la consulta exactamente como lo haría tu servicio.

  2. 2. Protocolo conservado

    Respeta el transporte seleccionado (UDP, TCP o DoH) para reproducir el comportamiento real.

  3. 3. Respuesta detallada

    Muestra las secciones question, answer y authority/additional cuando existen, con TTL y metadatos útiles.

¿Por qué usarla?

  • Comprobar la visión de un resolvedor específico antes de sospechar de la delegación
  • Confirmar los valores en caché y el impacto de un TTL o de un vaciado
  • Documentar una resolución tal como la ve un cliente o un microservicio

Truco: deja desactivada la opción de traza iterativa cuando audites un resolvedor concreto; actívala después para compararla con el recorrido raíz → TLD → autoritativo.

¿Cómo funciona la prueba de propagación?

La prueba consulta en paralelo un conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) y agrupa las respuestas por contenido y RCODE. Ves al instante quién ya aplicó la actualización.

  1. 1. Resolvedores multipunto

    Activa los presets de propagación para consultar a varios actores repartidos por el mundo.

  2. 2. Comparación automática

    Agrupa las respuestas idénticas y señala las divergencias o los errores propios de cada resolvedor.

  3. 3. Resumen accionable

    Ofrece un resumen claro, la lista de resolvedores, sus latencias y el estado de cada grupo.

¿Cuándo usarla?

  • Seguir la difusión de un cambio DNS a escala mundial
  • Identificar cachés aún antiguos y decidir un vaciado específico
  • Compartir un estado de propagación en un ticket o post-mortem

Truco: durante la prueba de propagación la selección de resolvedor queda bloqueada. Desactiva el modo para volver al diagnóstico unitario.

¿Qué es un registro SOA?

Un registro SOA (Start of Authority) define la autoridad de una zona DNS. Contiene la información esencial de la zona: servidor primario, contacto administrativo, número de serie y parámetros de sincronización.

Estructura de un registro SOA:

CampoDescripciónEjemplo
MNAMEServidor DNS primarions1.proveedor.com.
RNAMEContacto administrativo (email)hostmaster.captaindns.com.
SerialNúmero de versión de la zona2025012801
RefreshIntervalo de verificación (seg)7200
RetryTiempo después de fallo (seg)900
ExpireAbandono de zona (seg)1209600
MinimumCaché negativo (seg)3600

Ejemplo de registro SOA

captaindns.com.  3600  IN  SOA  ns1.proveedor.com. hostmaster.captaindns.com. (
    2025012801  ; Serial
    7200        ; Refresh (2 horas)
    900         ; Retry (15 minutos)
    1209600     ; Expire (14 días)
    3600        ; Minimum TTL (1 hora)
)

Explicación del contacto RNAME

El contacto se escribe como un nombre DNS: hostmaster.captaindns.com. corresponde al email hostmaster@captaindns.com. El primer punto reemplaza la arroba.


Valores recomendados

ParámetroValor recomendadoExplicación
Refresh3600-7200Verificación cada 1-2 horas
Retry600-900Reintento después de 10-15 minutos
Expire604800-1209600Abandono después de 1-2 semanas
Minimum300-3600Caché negativo de 5 min a 1 hora

Formato del serial

El formato AAAAMMDDNN es recomendado:

  • 2025012801 = 28 enero 2025, modificación n°1
  • 2025012802 = 28 enero 2025, modificación n°2

Reglas importantes

Unicidad del SOA

ReglaExplicación
Un solo SOASiempre en el apex de la zona
Con los NSSOA y NS coexisten en el apex
Sin CNAMEEl apex no puede ser un CNAME

Buenas prácticas

PrácticaPor qué
Incrementar el serialObligatorio en cada modificación
Contacto válidoPara recibir notificaciones
Expire suficienteEvita pérdida de zona en secundarios

Problemas comunes

Serial no incrementado

Los secundarios no se actualizan porque el serial no ha cambiado.

  1. Incremente el serial en la zona
  2. Recargue la zona en el primario
  3. Verifique la propagación

Sincronización fallida

Un servidor secundario muestra un serial antiguo.

  1. Verifique el acceso de red entre primario y secundario
  2. Controle los permisos de transferencia de zona
  3. Espere un ciclo de refresh

Zona abandonada por un secundario

El secundario ha superado el tiempo de expiración.

  1. Verifique que el primario sea accesible
  2. Aumente el valor expire si es necesario
  3. Fuerce una transferencia de zona

Verificación en línea de comandos

Linux/Mac

dig SOA captaindns.com

Comparar seriales en diferentes servidores:

dig SOA captaindns.com @ns1.proveedor.com +short
dig SOA captaindns.com @ns2.proveedor.com +short

Windows

nslookup -type=soa captaindns.com

Herramientas complementarias

HerramientaUtilidad
Búsqueda NSVerificar los servidores autoritativos
Búsqueda AVerificar la IP del servidor primario
Propagación DNSVerificar la propagación mundial

Recursos útiles