DNS explicado: Qué es y cómo afecta al rendimiento web con DNS.

La pieza invisible que puede sumar 50–300 ms a tu primera visita (y cómo optimizarla sin romper nada)

1) El DNS es el cuello de botella silencioso que no todos conocen bien.

Te mostraremos de la mejor manera como funciona y como puedes optimizar el rendimiento web con DNS, por temas de precisión usaremos términos técnicos, pero cada término tendrá un enlace externo que explica su definición lo más claro posible, ¿todo bien? entonces empecemos.

• ¿Por qué importa? Antes de descargar una sola imagen, fuente o script, el navegador necesita resolver el dominio a una IP.
• Ese “paso cero” es DNS. Si es lento o está mal configurado, la percepción de velocidad se resiente.
• Impacto típico:
  • Primera visita: 50–300 ms por dominio no cacheado (más en redes móviles o con mala cobertura).
  • Visitas posteriores: ~0 ms si está en caché y no ha expirado el TTL.
  • Sitios con muchos terceros (ads, analytics, widgets): cada dominio único puede añadir su propio lookup.
• Beneficio de optimizar DNS: mejor Time To First Byte (TTFB) percibido en primeras visitas, menos puntos de fallo y más resiliencia.

• El Sistema de Nombres de Dominio traduce nombres legibles (tudominio.com) a direcciones IP (por ejemplo 203.0.113.42 o un IPv6).

• Componentes clave del DNS:

• • Resolver recursivo: suele ser el de tu ISP o un público (1.1.1.1, 8.8.8.8). Hace el trabajo de “preguntar”.
  • Root y TLD servers: dirigen la consulta por la jerarquía (.com, .org, .es).
  • Authoritative nameservers: almacenan los registros “oficiales” de tu dominio.
  • Registros: A/AAAA (IP), CNAME (alias), MX (correo), TXT (varios), NS (nameservers), CAA, etc.

• Un Flujo simplificado de una primera visita:

1) El navegador pregunta al resolver recursivo por tudominio.com.

2) El recursivo consulta a los servidores raíz, que le indican los del TLD (.com).

3) El TLD señala los nameservers autoritativos de tudominio.com.

4) Los autoritativos responden con la IP (registro A/AAAA).

5) El resolver cachea la respuesta durante el TTL y la devuelve al navegador.

• Caché en todas partes:
  • Resolver recursivo (minutos a horas según TTL).
  • Sistema operativo y navegador (normalmente minutos).
  • Resultado: las siguientes visitas evitan el “viaje largo”.

• Lookup Time (búsqueda DNS):
  • Añade latencia antes de la conexión TCP/TLS.
  • En desktop con buena red: 20–80 ms típico por dominio no cacheado.
  • En móvil/3G o con alta latencia: 100–300+ ms.
• Multiplicadores de latencia:
  • Terceros: cada dominio nuevo implica lookup, TCP, TLS y posible bloqueo del render.
  • Cadena CNAME larga: alias que apuntan a otros alias antes de llegar a una IP (más pasos = más tiempo).
• Disponibilidad:
  • Si tu DNS cae, tu web “no existe” aunque el servidor esté bien.
  • Ataques DDoS al DNS y errores de configuración son causas frecuentes de caída total.
• Seguridad:
  • Envenenamiento de caché (cache poisoning) y spoofing.
  • DNSSEC firma criptográficamente respuestas para evitar manipulación.

• DNS Lookup (por dominio):
  • Objetivo: mantenerlo consistentemente <50 ms en regiones objetivo.
  • Alerta: >120 ms sostenidos en mercados clave indica proveedor o routing mejorable.
• TTL (Time To Live):
  • 300 s (5 min): cambios rápidos, más consultas.
  • 3600 s (1 h): equilibrio para la mayoría de sitios dinámicos.
  • 86400 s (24 h): sitios muy estables (landing, contenido estático).
• Registros y topología:
  • Número de dominios únicos en tu página crítica (LCP/hero): ideal ≤3–5.
  • Profundidad de cadenas CNAME: preferible ≤1 salto.
• Uptime y dispersión geográfica:
  • Autoritativos en ≥2 regiones y ≥2 redes (providers) distintos si es posible.

• Chrome DevTools:

1) Abre la pestaña Network. 2) Activa “Disable cache”. 3) Recarga duro (Cmd/Ctrl+Shift+R). 4) En la primera solicitud, mira “Queuing” y “Stalled” y sobre todo “DNS Lookup”.

• cURL (times):
  • curl -o /dev/null -s -w «dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n» https://tudominio.com
• dig/nslookup:
  • dig +trace tudominio.com
  • dig A tudominio.com @1.1.1.1
  • dig A tudominio.com @8.8.8.8
  • Compara latencias y respuestas.
• WebPageTest/Lighthouse:
  • Observa “First DNS” y la cascada. Verifica cuántos dominios nuevos aparecen antes del LCP.

• Elige un proveedor autoritativo rápido y con Anycast:
  • Busca red global, SLA alto, mitigación DDoS, soporte DNSSEC y health checks.
• Ajusta TTL con intención:
  • Producción estable: 1 h (3600) a 24 h (86400) para A/AAAA y CNAME.
  • Durante migraciones: bájalo a 60–300 s 24–48 h antes; tras el cambio y verificación, vuelve a subirlo.
• Reduce dominios únicos críticos:
  • Consolida terceros; evita cargar SDKs no esenciales “above the fold”.
  • Si usas CDN, intenta que fuentes/imagenes críticas vengan del mismo dominio/subdominio para reutilizar conexión.
• Corta cadenas CNAME:
  • Pide endpoints directos (A/AAAA) a tus proveedores o usa CNAME planos donde proceda.
• Prefetch y preconnect:
  • Acelera primeras visitas resolviendo y negociando antes de usarlos.
  • En el :

dns-prefetch solo resuelve; preconnect hace DNS + TCP + TLS.

Pasos para Habilitar el DNSSEC (Datos para técnicos)

Estos pasos pueden ser un poco pesados para las personas que no tienen un conocimiento intermedio del uso de DNS y configuraciones y diseño web.

Paso 1: Actívalo en tu proveedor autoritativo y publícalo en el registrador (DS record).

• ¿Cual es el Beneficio de hacer esto?: La integridad de respuestas; baja el impacto de latencia mínimo en navegadores modernos.

Paso 2: Health checks y failover:

• Configura comprobaciones y conmutación por error a un backend alternativo o región distinta.
• Para E-Commerce y SaaS, considera DNS autoritativo multi-provider.

Paso 3: Coloca registros adecuados y limpios:

• Evita comodines innecesarios.
• Mantén TXT ordenados (SPF, DKIM, verificación).
• Verifica que el AAAA exista si anuncias IPv6 en CDN/backend (evita timeouts de Happy Eyeballs).

• “Mi cambio no se ve”: TTL aún vigente o caches intermedias. Planifica cambios bajando TTL con antelación.
• “DNS lookup alto en ciertos países”: tu proveedor no tiene PoPs cercanos o hay peering deficiente. Cambia a proveedor con mejor presencia local o activa rutas Anycast adicionales.
• “Cadena CNAME infinita”: reconfigura a endpoint directo o pide flattening al proveedor.
• “Caídas por autoritativos únicos”: añade un segundo provider o al menos nameservers en AS distintos.
• “Intermitencia por DNSSEC mal configurado”: verifica registros DS/KSK/ZSK y cadena de confianza; usa validadores online antes de activar en producción.

• 72 h antes:
  • Reduce TTL de A/AAAA/CNAME a 300 s.
  • Documenta registros actuales y exporta zona.
• Día D:
  • Apunta nuevos registros al backend/CDN nuevo.
  • Verifica con dig desde varios resolvers (1.1.1.1, 8.8.8.8) y regiones si puedes.
• Post-cambio:
  • Monitoriza errores de resolución, 4xx/5xx y tiempos de DNS en RUM/APM.
  • Cuando todo esté estable, sube TTL a 3600–86400 s.
• Rollback plan:
  • Mantén configuración anterior lista para revertir en 1 clic si hay problemas.

• ¿Cuánto tarda la “propagación”?
  • Bueno, Técnicamente depende del TTL y caches existentes. En la práctica, la mayoría de cambios bien planificados se ven en minutos; los cambios de nameservers pueden tardar horas.
• ¿Cuántos dominios terceros son “demasiados”?
  • No hay número mágico, pero intenta que los recursos críticos antes del LCP vengan de ≤3–5 dominios. Relega extras a carga diferida.
• ¿DNSSEC me hará más lento?
  • El impacto suele ser marginal para usuarios finales; el beneficio de seguridad compensa en la mayoría de casos.
• ¿Puedo medir DNS por usuario real?
  • Sí: RUM via Performance API del navegador y tu APM

(p. ej., performance.timing.domainLookupStart/End).

---

• A: IPv4 del host (www → 203.0.113.42)
• AAAA: IPv6 del host
• CNAME: alias (www → raiz.dominio)
• NS: nameservers autoritativos de la zona
• MX: correo
• TXT: SPF/DKIM/DMARC/verificaciones
• CAA: qué CA puede emitir certificados para tu dominio

Visita nuestro Blog

• Página con:
  • Dominio principal (no cacheado): DNS 45 ms
  • CDN imágenes (no cacheado): DNS 68 ms
  • Analytics (no cacheado): DNS 92 ms
• Total añadido en primera visita: ~205 ms antes de descargar recursos.
• Optimización aplicada:
  • Preconnect a CDN y consolidación de analytics → -120 ms en primera interacción.
  • TTL de registros clave subido a 3600 s → más aciertos de caché en segundas visitas.

• DNS es un pilar invisible del rendimiento: cada dominio no cacheado puede añadir decenas o cientos de milisegundos que se sienten, sobre todo en móvil y primeras visitas.
• Centra tu estrategia en tres frentes: proveedor autoritativo rápido con Anycast + reducción de dominios y CNAMEs + TTL gestionado inteligentemente (y preconnect donde aporte).
• Con medición continua y cambios planificados, puedes ganar hasta cientos de milisegundos en percepción de velocidad sin tocar ni una línea de tu backend.