Búsqueda registro MX

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 MX

Un registro MX indica qué servidores reciben el correo para un dominio. Apunta hacia un nombre de host. El resolutor sigue este nombre para encontrar registros A o AAAA. El servidor remitente puede entonces entregar los mensajes.
Un registro MX contiene un nombre, un tipo, una prioridad, un destino y un TTL. El TTL indica cuánto tiempo permanece la respuesta en caché en el resolutor local.

Ejemplo registro DNS de tipo MX

NombreTipoPrioridadDestinoTTL en segundos
@MX10mail.ejemplo.net.3600

En este ejemplo, el nombre @ apunta a la raíz del dominio. El destino es un nombre de host que debe publicar A o AAAA. Se prefiere una prioridad más baja. Un TTL de 3600 corresponde a una hora.

Ejemplo con múltiples prioridades

Publicar múltiples registros MX para el mismo nombre es común. El servidor remitente elige primero la prioridad más baja. En caso de fallo, intenta la siguiente.

NombreTipoPrioridadDestinoTTL en segundos
@MX10mx1.ejemplo.net.3600
@MX20mx2.ejemplo.net.3600

Esta redundancia aumenta la continuidad del servicio. No reemplaza una supervisión activa ni pruebas regulares.

Reglas esenciales

Un registro MX apunta hacia un nombre, no hacia una dirección. El destino no debe ser un CNAME. El nombre objetivo debe publicar A o AAAA y ser alcanzable en el puerto 25. El MX puede existir en el ápice o en un subdominio si la dirección de correo utiliza ese subdominio.

TTL explicado claramente

Un TTL corto hace un cambio visible más rápido. Útil al pasar a un nuevo servicio de mensajería.
Un TTL medio o largo reduce las consultas hacia los servidores autoritativos. Apropiado para un servicio estable.
Reducir el TTL unas horas antes del cambio, luego aumentarlo cuando todo esté validado.

Bueno saber
Los registros MX sirven para la recepción. El correo saliente utiliza otras configuraciones como SPF, DKIM, DMARC y la configuración del relé saliente.

Dónde usar un registro MX

Publicar el MX en el dominio que recibe el correo. Más a menudo, es la raíz. Para un dominio dedicado como support.ejemplo.com, publicar el MX en ese subdominio. Los hosts de mensajería referenciados por los registros MX mantienen sus propios A o AAAA.

A evitar
Apuntar un MX hacia un CNAME o hacia una dirección directa.
Olvidar el registro A o AAAA del destino.
Dejar un MX antiguo activo después de una migración.

Verificar en línea

Una búsqueda DNS en línea permite ingresar un nombre de dominio. Se obtiene la lista de MX con sus prioridades, sus destinos y el TTL visible desde Internet. Es un primer control útil. Hacer luego una prueba local desde su máquina.

Verificar bajo Windows

Windows proporciona nslookup. Se puede usar en modo interactivo.

Resolutor local
nslookup
set q=mx
ejemplo.com
Resolutor específico
nslookup
set q=mx
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 tercero, aquí el de Cloudflare.

Verificar bajo Linux y bajo Mac

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

Resolutor local
dig MX ejemplo.com
Resolutor específico
dig MX ejemplo.com @1.1.1.1

Lectura rápida de las respuestas

Múltiples líneas indican múltiples servidores. El número de prioridad más pequeño es preferido. Prioridades idénticas comparten los intentos de manera equilibrada.
Un TTL restante alto puede explicar un desfase después de un cambio.
Un destino sin A ni AAAA impide la entrega.

Procedimiento de migración simple

  1. Preparar los hosts de mensajería con sus A o AAAA.
  2. Reducir el TTL de los MX a 300 o incluso 60 segundos unas horas antes del cambio.
  3. Agregar los nuevos MX con la prioridad prevista. Conservar los antiguos durante la transición.
  4. Probar la recepción desde múltiples redes. Verificar las cabeceras de los mensajes recibidos.
  5. Retirar los MX antiguos, luego aumentar el TTL cuando todo esté estable.

Consejo práctico
Anotar la lista completa de MX antes de la modificación. Conservar la fecha, las prioridades, el TTL y la razón del cambio. Esta traza evita errores y facilita una vuelta atrás.

Casos frecuentes

Servicio de mensajería externo

Publicar los MX proporcionados por el proveedor. Los destinos pertenecen al dominio del proveedor. Mantener un TTL razonable.

Filtrado antispam aguas arriba

Apuntar los MX hacia el proveedor de filtrado. Este proveedor luego retransmite hacia sus servidores. Monitorear la latencia y la disponibilidad.

MX de respaldo

Declarar un servidor secundario con una prioridad más alta. Retiene los mensajes si el servidor principal no está disponible, luego los entrega cuando regresa.

Resolución rápida de problemas

  1. En caso de rebote, verificar que el destino del MX resuelve en A o AAAA.
  2. Verificar la accesibilidad de red en el puerto 25 hacia el destino.
  3. Si los MX aún apuntan hacia el proveedor anterior, retirarlos después del cambio.
  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 MX indica el servidor de recepción para un dominio. Apunta hacia un nombre de host que publica A o AAAA. La prioridad más baja es elegida primero. Un TTL bien elegido facilita los cambios. La verificación pasa por una herramienta en línea, luego por nslookup y por dig.
Con estas referencias, la gestión permanece clara. Los cambios se desarrollan sin estrés. Los mensajes llegan sin incidentes.