Algo se ha roto. El sitio no carga, los correos rebotan, o cambiaste un registro hace una hora y no pasa nada. Nueve de cada diez veces la respuesta está en el DNS: solo hay que saber dónde mirar.
El DNS es la agenda de direcciones de internet: convierte example.com en una IP a la que tu navegador puede conectarse de verdad. Cuando funciona mal, todo lo que viene después parece roto aunque el servidor esté perfecto. Veamos cómo leerlo como es debido.
Los registros que conviene conocer
No hace falta memorizarlos todos. Estos son los que aparecen:
| Registro | Qué hace | Cuándo te muerde |
|---|---|---|
| A | Asigna un nombre a una dirección IPv4 | El sitio apunta al servidor equivocado/viejo |
| AAAA | Lo mismo, pero IPv6 | Los usuarios de IPv6 no te alcanzan |
| MX | A dónde va el correo del dominio | El correo rebota o desaparece |
| TXT | Texto libre — SPF, DKIM, verificación | El correo cae en spam; la verificación falla |
| NS | Qué servidores de nombres son autoritativos | Todo el dominio resuelve mal |
| CNAME | Un alias que apunta un nombre a otro | Un subdominio no resuelve |
| SOA | Metadatos de administración de la zona | Rara vez — pero nombra el NS primario |
| CAA | Qué CA pueden emitirte certificados | La emisión del certificado se rechaza |
Nuestra herramienta de consulta DNS consulta los diez tipos que admite — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV y PTR — contra el que elijas: Google (8.8.8.8), Cloudflare (1.1.1.1) o Quad9 (9.9.9.9), y muestra la salida en bruto estilo dig con los TTL intactos. Lees lo mismo que ve un sysadmin en una terminal.
¿Detectas un registro A que apunta a una IP que no reconoces? IP WHOIS te dice en segundos de quién es.
TTL: el número que todos ignoran hasta que importa
Cada registro lleva un TTL — time to live, en segundos. Es cuánto tiempo se permite a los resolvers cachear la respuesta antes de volver a preguntar. Un TTL de 3600 significa «fíate de esto durante una hora».
Ese único número explica casi todo el pánico de «mi cambio de DNS no funciona». Un ejemplo sencillo: corriges un registro A a las 12:00, pero su TTL es 86400 (un día entero). Los resolvers que consultaron tu dominio a las 11:30 seguirán devolviendo la IP vieja durante casi 24 horas más — así que para algunos usuarios el sitio solo «se mueve» al día siguiente. No se rompió nada; simplemente les dijiste que podían cachear esa respuesta durante un día.
La regla práctica que seguimos: baja el TTL un día antes de planear cambiar un registro. Bájalo a 300 segundos, espera a que expire el TTL alto anterior y entonces haz el cambio. Ahora el cambio se propaga en minutos en vez de en un día. Súbelo de nuevo después para que los resolvers no estén reconsultando tus servidores de nombres todo el rato.
«Lo cambié, ¿por qué no está activo?»
Porque el DNS no tiene botón de actualizar. No hay un servidor central al que empujar. Tu servidor de nombres autoritativo tiene el valor nuevo al instante, pero cada resolver que ya cacheó el viejo lo seguirá sirviendo hasta que expire su TTL. Y distintos resolvers, en distintos países, expiran en momentos distintos.
Por eso hicimos el comprobador de propagación DNS como lo hicimos. En lugar de preguntar a un resolver y darlo por hecho, lanza la misma consulta a 15 resolvers públicos repartidos por el mundo, en paralelo — Google y Cloudflare en EE. UU., Quad9 en Suiza, Mullvad en Suecia, CZ.NIC en Chequia, Alibaba y DNSPod en China, y más. Ves cómo el registro nuevo se va encendiendo región por región a medida que expiran las cachés. Cuando los 15 coinciden, estás propagado de verdad.
Regla general: la «propagación» no es internet yendo lento. Son cachés respetando el TTL que pusiste.
Cuando el problema es el propio resolver
A veces los registros son correctos en todas partes y el sitio aun así resuelve con lentitud. Eso apunta a la latencia del resolver, no a los valores de los registros.
Nuestra herramienta de tiempo de respuesta DNS mide exactamente eso: ejecuta dig contra esos mismos 15 resolvers, varias veces cada uno, e informa del mínimo, el máximo y el tiempo medio de consulta por resolver. Si tus usuarios están en Alemania y tus servidores de nombres responden a Frankfurt en 8 ms pero a Sídney en 280 ms, eso es una señal real y medible — quizá sea hora de un proveedor de DNS anycast.
Quién controla la zona: WHOIS y servidores de nombres
Si los registros NS parecen mal, la pregunta pasa a ser quién los puso. Domain WHOIS te da el registrador, las fechas de registro y caducidad, los códigos de estado del dominio, si DNSSEC está activo y —lo crucial— los servidores de nombres que la registry tiene en sus archivos.
Algo que conviene saber, porque las herramientas baratas lo hacen mal: muchas extensiones nuevas como .tools, .app y .dev no tienen un servidor WHOIS tradicional en absoluto. Consúltalas a la antigua y no obtienes nada. Nuestra consulta recurre automáticamente a RDAP —el reemplazo moderno basado en JSON— en cuanto detecta una respuesta WHOIS fina o ausente, así que un dominio .tools devuelve el mismo resultado estructurado que un .com. Nos topamos con esto en nuestro propio dominio, de hecho. El arreglo se convirtió en una función.
Si los servidores de nombres en la registry no coinciden con lo que pusiste en tu proveedor de DNS, has encontrado tu fallo: el dominio apunta a un sitio completamente distinto, y ninguna edición de registros ayudará hasta que se arregle la delegación de NS.
Una lista rápida cuando el DNS «no funciona»
- Consulta el registro que cambiaste con la herramienta de consulta. ¿Está siquiera el valor nuevo?
- Comprueba el TTL. ¿Alto? Solo estás esperando a que expire la caché.
- Haz una comprobación de propagación. Resultados mixtos entre regiones = las cachés aún expiran; consistente en todas partes = está activo.
- Verifica los registros NS contra tu proveedor de DNS con WHOIS. Un desajuste de delegación es el verdadero culpable más a menudo de lo que crees.
- ¿Sigue lento? Mide el tiempo de respuesta del resolver antes de culpar a tu aplicación.
En resumen
La mayoría de las «caídas» de DNS no son caídas. Son TTL haciendo exactamente lo que les dijiste, o una delegación apuntando a un sitio que olvidaste. Lee los registros, respeta el TTL y comprueba la propagación en más de un resolver antes de concluir nada. Empieza con una consulta: la respuesta suele estar justo ahí, en la salida.
— el equipo de checkbox.tools