Búsqueda registro TXT

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

¿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.

Información adicional sobre los registros DNS tipo TXT

Un registro TXT publica un texto asociado a un nombre de dominio. Los servicios lo utilizan para demostrar la propiedad del dominio, configurar la mensajería como SPF DKIM DMARC o exponer información técnica.
Un registro TXT contiene un nombre, un tipo, un valor y un TTL. El TTL indica cuánto tiempo permanece la respuesta en caché en el resolutor local.

Ejemplo registro DNS de tipo TXT

NombreTipoValorTTL en segundos
@TXT"v=spf1 ip4:203.0.113.0/24 ~all"3600

En este ejemplo, el nombre @ apunta a la raíz del dominio. El valor contiene una regla SPF en texto. Un TTL de 3600 corresponde a una hora.

Ejemplos comunes

NombreTipoValorTTL en segundos
selector1._domainkeyTXT"v=DKIM1; k=rsa; p=MII...AB"3600
_dmarcTXT"v=DMARC1; p=quarantine; adkim=s; aspf=s"3600
@TXT"propiedad=token12345"300

Estas líneas muestran un selector DKIM, una política DMARC y un token de verificación. El nombre objetivo depende del servicio utilizado.

Múltiples TXT en el mismo nombre

Es posible publicar múltiples registros TXT en la misma etiqueta. Cada valor aparece en la respuesta. Para SPF, mantener una sola entrada por nombre y agrupar los mecanismos en ella. Para DKIM, usar un selector diferente para cada clave.

TTL explicado claramente

Un TTL corto hace que un cambio sea visible más rápido. Útil durante una actualización de SPF o una verificación de dominio.
Un TTL medio o largo reduce las consultas hacia los servidores autoritarios. Adecuado para una configuración estable.
Reducir el TTL unas horas antes de la modificación y luego subirlo después de la validación.

Bueno saber
Un valor TXT puede superar los 255 bytes. Entonces se divide en múltiples cadenas entre comillas en la zona. Los resolutores unen estas cadenas del lado del cliente.

Dónde usar un registro TXT

Publicar el TXT en el nombre solicitado por el servicio. SPF se coloca a menudo en el ápice. DKIM se publica en selector._domainkey. DMARC se coloca en _dmarc. Los servicios de verificación proporcionan un nombre específico. Un TXT puede coexistir con A AAAA MX en el mismo nombre.

A evitar
Tener dos entradas SPF en el mismo nombre. Fusionar en un solo valor.
Olvidar las comillas o escapar mal los caracteres especiales.
Publicar un DKIM en el selector incorrecto.

Verificar en línea

Una búsqueda DNS en línea permite introducir un nombre de dominio. Se obtiene la lista de valores TXT así como el TTL visible desde Internet. Es una primera verificación útil. Luego hacer una prueba local desde su máquina.

Verificar en Windows

Windows proporciona nslookup. Se puede usar en modo interactivo.

Resolutor local
nslookup
set q=txt
ejemplo.com
Resolutor específico
nslookup
set q=txt
server 1.1.1.1
ejemplo.com

La primera parte consulta según la configuración de red de la máquina. La segunda fuerza el uso de un resolutor externo, aquí el de Cloudflare.

Verificar en Linux y Mac

En estos sistemas, el comando dig es práctico y fácil de usar.

Resolutor local
dig TXT www.ejemplo.com
Resolutor específico
dig TXT www.ejemplo.com @1.1.1.1

Lectura rápida de respuestas

Múltiples líneas indican múltiples valores TXT. Leer los prefijos v=spf1 v=DKIM1 v=DMARC1 para identificar la función de cada entrada.
Un TTL restante alto puede explicar un desfase después de un cambio.
Un valor vacío o truncado a menudo señala una comilla faltante o un corte mal gestionado.

Procedimiento de migración simple

  1. Anotar los valores actuales y el TTL.
  2. Reducir el TTL a 300 o incluso 60 segundos unas horas antes de la modificación.
  3. Preparar el nuevo valor. Para SPF, fusionar los mecanismos en una sola línea.
  4. Publicar el nuevo valor y luego retirar el antiguo si es necesario.
  5. Verificar con nslookup o con el comando dig desde varias redes y subir el TTL cuando todo esté estable.

Consejo práctico
Para DKIM, publicar una nueva clave en un nuevo selector. Dejar la antigua durante el tiempo de transición. Luego retirar la clave antigua cuando todo esté validado.

Casos frecuentes

SPF para la recepción correcta de correos

Publicar una regla SPF en el ápice con las direcciones y dominios autorizados. Probar antes de la puesta en producción.

DKIM para firmar mensajes

Publicar la clave pública en el selector proporcionado por el servicio de mensajería. Verificar que la clave esté completa.

DMARC para la política de dominio

Publicar una política en _dmarc con la directiva p y las opciones útiles. Supervisar los informes si están activados.

Verificación de propiedad

Publicar un token TXT temporal proporcionado por un servicio. Retirarlo después de la validación si el servicio lo permite.

Solución de problemas rápida

  1. Si SPF es reportado como inválido, verificar que solo existe una entrada SPF en el mismo nombre.
  2. Si DKIM falla, verificar el selector y la clave. Buscar un corte o un espacio de más.
  3. Si DMARC no es detectado, verificar el nombre _dmarc y el valor v=DMARC1.
  4. Si la respuesta permanece antigua, esperar la expiración del TTL y purgar la caché del resolutor local si es posible.

En resumen, un registro TXT publica información de texto para un nombre de dominio. Sirve para verificaciones, políticas de mensajería y otros usos técnicos. El TTL controla la duración de caché. Múltiples TXT pueden coexistir en el mismo nombre, pero solo debe existir una entrada SPF. La verificación pasa por una herramienta en línea, luego por nslookup y por dig.
Con estas pautas, la gestión permanece clara. Los cambios se realizan sin estrés. Los servicios funcionan como se espera.