Cómo funciona el DNS: resolución, registros y por qué a veces tarda

Cada vez que cargas una web ocurre antes algo invisible y asombroso: tu dispositivo pregunta a una jerarquía global distribuida cuál es la IP de ese dominio, y recibe respuesta en milisegundos. Ese sistema —el DNS— es la guía telefónica de internet y su funcionamiento explica desde por qué un dominio "no se propaga" hasta cómo los atacantes pueden secuestrar tu correo.

La resolución completa: el viaje de una consulta

Escribes miguelacm.es y el navegador necesita una IP. Lo que ocurre detrás:

1. Cachés locales: navegador, luego sistema operativo. Si ya conocen la respuesta y no ha caducado (TTL), fin.
2. Resolver recursivo: si nadie la tiene, la consulta viaja al resolver configurado — el de tu router o uno público como 1.1.1.1 u 8.8.8.8. Este hace el trabajo pesado y guarda su propia caché compartida entre usuarios.
3. Root servers: si tampoco la tiene, pregunta a uno de los 13 grupos de servidores raíz (a.root-servers.net...m.). Ellos no saben dónde está miguelacm.es, pero sí quién gestiona .es: responden con las direcciones de los TLD servers de ese dominio de primer nivel.
4. TLD servers (Verisign/red.es para .es): no conocen la IP final, pero sí los nameservers autoritativos del dominio — dondequiera que esté alojada su zona DNS.
5. Nameserver autoritativo: la única fuente de verdad. Responde con el registro definitivo, que regresa por el mismo camino acumulándose en cada caché según su TTL.

Todo este recorrido ocurre típicamente en 10-100 ms gracias a que el 90% de consultas nunca pasa del paso 1 o 2.

Los registros que importan

Una zona DNS es una tabla de registros tipados:

Matices que evitan errores reales:

• Un CNAME no puede coexistir con otros registros en el mismo nombre. Por eso el apex (midominio.es) suele usar A/ALIAS/ANAME y los subdominios usan CNAME libremente.
• MX y CNAME tampoco mezclan: el dominio que recibe correo necesita MX directos, sin alias en medio.
• Los TXT hacen mucho más trabajo del que aparentan: SPF declara qué servidores pueden enviar email en nombre del dominio, DKIM publica claves para firmar mensajes, y ACME usa registros TXT para validar dominios al emitir certificados wildcard.

TTL: el parámetro que gobierna los cambios

Cada registro lleva un TTL (time to live) en segundos: cuánto tiempo cualquier caché intermedia puede retenerlo. TTL 3600 = hasta una hora de propagación residual tras un cambio.

La estrategia profesional al migrar de servidor: bajar el TTL a 60 segundos 24 horas antes del cambio, hacer la migración, verificar, y volver a subir el TTL a su valor normal (3600-86400). Así el cambio se propaga rápido cuando lo haces, pero después ahorras tráfico y consultas con cachés largas.

"Mi DNS no se propaga" casi siempre significa: tu resolver local aún cachea el valor viejo dentro de su TTL. No hay propagación mágica planetaria — hay cachés independientes caducando a ritmos distintos.

Cuando el DNS falla o miente

Los fallos típicos tienen diagnóstico directo:

• NXDOMAIN (el dominio no existe): registro inexistente, typo, o el dominio caducó. Verifica whois.
• SERVFAIL: el nameserver autoritativo está caído o responde mal. El dominio existe pero nadie contesta bien.
• Respuestas lentas: resolver saturado o cadena larga; probar un resolver público distinto lo confirma.
• Registros viejos pese a cambiarlos: caché local (ipconfig /flushdns), caché del resolver público, o simplemente TTL aún vivo.

Y las amenazas serias:

• DNS spoofing/cache poisoning: un atacante logra que un resolver cachee una IP falsa para tu dominio. Mitigación: DNSSEC, que firma criptográficamente los registros y permite validar la cadena desde la raíz.
• Secuestro de correo por SPF laxo: si tu TXT de SPF dice +all o no existe, cualquiera puede enviar email fingiendo ser tu dominio. La tríada SPF + DKIM + DMARC lo cierra.
• Subdomain takeover: un registro CNAME apunta a un servicio que has dejado de usar; quien reclame ese servicio externo controla el subdominio. Audita periódicamente registros huérfanos — nuestro buscador de subdominios vía Certificate Transparency ayuda a descubrir qué tienes publicado y olvidado.

Depurar con dig como un profesional

La herramienta universal (incluida en Linux/macOS, disponible en Windows vía WSL o nslookup):

# Consulta directa al resolver por defecto
dig miguelacm.es

# Preguntar a UN nameserver concreto (bypasea cachés)
dig @ns1.vercel-dns.com miguelacm.es

# Otros tipos de registro
dig miguelacm.es MX
dig miguelacm.es TXT +short

# Ver la ruta completa de delegación
dig +trace miguelacm.es

+trace es oro para diagnósticos: replica la consulta real paso a paso (root → TLD → autoritativo) y muestra exactamente en qué eslabón se rompe una delegación.

Consulta tus propios registros

Nuestro consulta DNS online ejecuta estas consultas desde tu navegador y presenta todos los tipos de registro de cualquier dominio en formato legible — la forma rápida de revisar una zona sin abrir terminal.

Preguntas frecuentes

¿Qué resolver público me conviene? Para privacidad y velocidad, 1.1.1.1 (Cloudflare) o 9.9.9.9 (Quad9, filtra malware). Las diferencias de latencia entre grandes resolutores son mínimas en la práctica; la política de logs y filtrado importa más.

¿Cambiar nameservers afecta a mi web? Solo si los nuevos nameservers no contienen la misma zona. Antes de mover nameservers, replica TODOS los registros en la nueva zona y verifica con dig contra ellos.

¿Por qué mi subdominio funciona en móvil pero no en WiFi del trabajo? Redes corporativas con resolvers propios que filtran o cachean agresivamente. Compara respuestas entre tu resolver local y uno público para confirmarlo.

Consulta los registros DNS de cualquier dominio con nuestra herramienta DNS Lookup, gratis y directamente en tu navegador.