Consulta DNS

Qué hace esta herramienta

Escribes un dominio y obtienes todos sus registros DNS públicos de una vez: A, AAAA, CNAME, MX, NS, TXT y SOA, cada uno con su valor y, donde aplica, su prioridad y su TTL. Es la misma información que devuelve dig o nslookup en una terminal, pero sin instalar nada y agrupada por tipo para que se lea de un vistazo.

La consulta se hace desde el servidor de esta página contra los resolvedores públicos, así que ves lo que ve el resto de internet, no lo que tiene cacheado tu ordenador o el router de tu casa. Esa diferencia es, precisamente, la causa del error más frecuente que trae a la gente aquí.

Cómo usarla

1. Escribe el dominio sin https:// ni barra final: ejemplo.com, o un subdominio como correo.ejemplo.com.
2. Pulsa Buscar registros DNS.
3. Cada tipo de registro sale en su propia tabla. Si un tipo no aparece, es que el dominio no lo tiene publicado.

No se consulta ningún registro privado ni se hace nada que un resolvedor normal no haga: es una lectura pública.

Qué significa cada tipo de registro

La prioridad de los MX es menor = más prioritario: el servidor con 10 recibe antes que el de 20, que solo entra si el primero no responde.

«Cambié el DNS y no se ve»: casi nunca es la propagación

Es el motivo número uno de consulta, y la explicación habitual («tarda hasta 48 horas en propagarse») es más leyenda que técnica. El DNS no se propaga: cada resolvedor pregunta cuando lo necesita y guarda la respuesta el tiempo que marque el TTL del registro. Si tu registro A tenía un TTL de 86.400 segundos (un día), cualquier resolvedor que lo consultó esta mañana seguirá devolviendo la IP vieja hasta mañana, aunque el cambio ya esté publicado.

Por eso la secuencia correcta al migrar un servidor es:

1. Días antes, bajar el TTL del registro a 300 segundos (cinco minutos) y esperar a que caduque el TTL antiguo.
2. Hacer el cambio de IP.
3. Cuando todo esté estable, devolver el TTL a un valor alto.

Si ya cambiaste la IP sin bajar el TTL, no hay forma de acelerar a los resolvedores ajenos; solo cabe esperar a que expire. Con esta herramienta ves el valor que ya está publicado; con la de propagación DNS ves qué resolvedores del mundo lo han recogido ya.

Hay un segundo caso menos conocido: la caché negativa. Si consultaste un registro antes de crearlo, la respuesta «no existe» también se guarda, durante el tiempo que indica el campo minimum del SOA. Crear el registro y comprobarlo en el mismo minuto desde tu equipo puede darte un «no existe» falso.

El error del CNAME en la raíz del dominio

Un CNAME dice «este nombre es un alias de aquel otro» y no puede convivir con ningún otro registro en el mismo nombre. La raíz del dominio (ejemplo.com a secas) tiene obligatoriamente SOA y NS, así que no admite un CNAME: la mayoría de paneles lo rechazan y los que lo aceptan rompen el correo, porque los MX dejan de resolverse.

Si necesitas que la raíz apunte a un CDN o a un SaaS que solo te da un nombre y no una IP, las opciones son un registro A con la IP del proveedor o el «CNAME flattening» / registro ALIAS que ofrecen Cloudflare, Route 53 y otros. En www sí puedes usar CNAME sin problema, y es lo habitual.

Los TXT: SPF, DMARC y la basura que se acumula

En la tabla TXT suelen aparecer tres cosas: el registro SPF (v=spf1 …), verificaciones de propiedad (google-site-verification=…, MS=…) y restos de servicios que ya no se usan. Dos comprobaciones rápidas:

• Solo puede haber un SPF. Dos registros que empiecen por v=spf1 invalidan la autenticación entera; los servidores de correo lo tratan como error permanente. Si contrataste un servicio nuevo y añadiste «otro SPF», ese es el fallo.
• El DMARC no sale aquí porque vive en _dmarc.ejemplo.com, no en la raíz. Consúltalo con el subdominio o directamente en la comprobación de DMARC.

Las verificaciones antiguas no hacen daño, pero cada TXT cuenta para el límite de tamaño de la respuesta; si acumulas quince, conviene limpiar.

El SOA: el serial que confirma el cambio

El registro SOA trae el serial de la zona, un número que el servidor primario incrementa con cada modificación. Si acabas de cambiar algo y el serial sigue siendo el de la semana pasada, el cambio no se ha guardado o no ha salido del primario: no es un problema de caché, es que todavía no existe. Muchos proveedores usan el formato AAAAMMDDnn (fecha más dos cifras), lo que hace fácil ver de cuándo es la última edición.

Los otros campos (refresh, retry, expire, minimum) regulan cómo se sincronizan los servidores secundarios y cuánto dura la caché negativa. Rara vez hay que tocarlos.

Preguntas que resuelve

• ¿A qué IP apunta mi dominio ahora mismo? → tabla A (y AAAA para IPv6).
• ¿Quién gestiona mi correo? → tabla MX: si dice google.com, outlook.com o mail.protection…, ya tienes la respuesta.
• ¿Dónde está administrado mi DNS? → tabla NS.
• ¿Tengo SPF? ¿Tengo dos? → tabla TXT.
• ¿Por qué el cambio no se ve? → mira el TTL, luego la propagación.
• ¿Cómo está todo en conjunto? → el informe de salud del dominio revisa DNS, correo, TLS y cabeceras a la vez.