Para qué sirve una consulta DNS
Diagnosticar el origen de una caída de sitio.
Verificar un cambio antes de una puesta en producción.
Confirmar la propiedad de un dominio durante una verificación por TXT.
Configurar SPF DKIM DMARC BIMI y controlar la visibilidad.
Preparar una migración con TTL reducido y seguir el efecto real en la red.
Comparar la respuesta vista desde tu estación con la vista desde otras regiones.
Bueno saber
Se habla a menudo de propagación DNS. En realidad el sistema cachea las respuestas según el TTL. Mientras este tiempo no haya expirado algunos resolvers mantienen el valor anterior. La palabra propagación sigue siendo práctica para describir este efecto.
Lo que hace la herramienta
Resolución recursiva completa desde la raíz hasta los servidores autoritativos.
Elección de un resolver público como Google Cloudflare Quad9 OpenDNS Yandex o del servidor autoritativo cuando es pertinente.
Visualización de respuestas brutas con TTL y datos.
Trace iterativo opcional que muestra cada salto y la latencia.
Lectura clara cuando no se encuentra respuesta estructurada.
Funcionamiento de una consulta DNS
Tu dispositivo solicita la respuesta al resolver configurado en la estación o en el router.
El resolver consulta primero su caché local.
Sin respuesta, interroga un servidor raíz que le indica el servidor del dominio de primer nivel.
El servidor TLD redirige hacia los servidores autoritativos del nombre buscado.
El resolver interroga un servidor autoritativo que devuelve el registro solicitado con su TTL.
El resolver cachea la respuesta para acelerar las próximas consultas y la envía a tu dispositivo.
Consejo rápido
Para verificar un resultado desde tu estación, puedes usar nslookup en Windows y dig en Mac y Linux. Estos comandos leen la configuración local o un resolver elegido.
Entender el TTL y la famosa propagación
El TTL es una duración expresada en segundos. Indica cuánto tiempo puede permanecer una respuesta en caché.
Un TTL corto hace visible un cambio más rápido. Muy útil durante una migración.
Un TTL medio o largo reduce la carga en los servidores autoritativos. Bueno para un servicio estable.
Un proveedor de acceso puede mantener una respuesta más tiempo según su propia política de caché. Sucede que la actualización tarde más tiempo del esperado.
Truco práctico
Antes de un cambio reducir el TTL un poco por adelantado. Hacer el cambio. Controlar las respuestas desde varias redes. Luego subir el TTL elegido para la operación.
Cuándo lanzar una consulta DNS
Un sitio no responde más aunque el servidor esté en línea.
Acabas de modificar un registro y quieres ver la respuesta real.
Estás desplegando un nuevo servicio y debes validar A AAAA CNAME o MX.
Estás instalando SPF DKIM DMARC o BIMI y deseas confirmar la visibilidad pública.
Estás preparando una migración y quieres medir la latencia y el trace de extremo a extremo.
Lectura de una respuesta
Presencia de una o varias direcciones para A o AAAA
El cliente elige una dirección en la lista lo que distribuye la carga de forma simple.
Presencia de un CNAME
La respuesta muestra el objetivo. Verificar luego que el objetivo publique efectivamente A o AAAA.
Presencia de NS y SOA
La zona es servida por estos hosts. El serial del SOA debe avanzar después de cada actualización.
Respuesta vacía o NXDOMAIN
Ningún registro para este nombre. Verificar la ortografía, el subdominio y la zona.
TTL alto
Un desfase después de un cambio es posible mientras el caché no haya expirado.
Límites y puntos de atención
Un CNAME no debe coexistir con A AAAA MX o TXT en el mismo lugar.
En el apex de un dominio, se evita el CNAME. Usar un equivalente propuesto por el proveedor si está presente.
Un MX debe apuntar a un nombre que resuelva en A o AAAA. No CNAME como objetivo de MX.
Un PTR debe devolver un nombre que resuelva hacia la dirección original para mantener buena coherencia.
Los parámetros SVCB y HTTPS guían al cliente, pero no reemplazan A y AAAA.
Buenas prácticas para ganar tiempo
Documentar cada cambio con la fecha, el TTL y la razón.
Probar desde tu red luego desde resolvers públicos.
Comparar la respuesta del servidor autoritativo con la respuesta de un resolver público.
Monitorear los nombres críticos y establecer alertas en caso de cambio inesperado.
Conservar una captura del trace cuando ocurre un incidente para compartirla con un proveedor.
Preguntas frecuentes
¿En qué difiere de los comandos locales?
La herramienta interroga resolvers públicos y puede mostrar el trace completo. Los comandos locales siguen siendo útiles para un control rápido desde tu estación.
¿Cuánto tiempo para ver un cambio?
De unos minutos a varias horas según el TTL y los cachés en funcionamiento en los proveedores de acceso y en ciertos resolvers públicos.
¿Qué hacer si la respuesta difiere según las regiones?
Esperar la expiración del TTL. Purgar el caché local si es posible. Verificar la coherencia del lado de los servidores autoritativos.
¿Qué tipos de registros verificar en prioridad?
A AAAA CNAME MX TXT NS SOA siguen siendo la base. Según la necesidad agregar CAA PTR SRV SVCB o HTTPS. Con DNSSEC controlar DS y DNSKEY.