Cómo arreglar una consulta DNS lenta

Qué mide una consulta lenta

Cargar una página empieza con una consulta de nombre, luego una conexión TCP, luego un saludo TLS y después el tiempo que el servidor dedica a pensar. Solo la primera de esas fases es DNS, y suele ser la única que puedes mejorar sin tocar el sitio.

Aquí se confunden dos números. Una consulta en caché no cuesta casi nada, porque la respuesta ya está en tu equipo o a un salto de distancia. Una consulta en frío puede implicar una pregunta a la raíz, otra al dominio de primer nivel y otra a los servidores de nombres del propio dominio, cada una un viaje de ida y vuelta por la distancia que te separe de esos servidores. Menos de 20 ms en caliente y menos de 100 ms en frío no llaman la atención. Acercarse a un segundo significa que alguno de los saltos está lejos, sobrecargado, o agotando el tiempo y siendo reintentado.

Las páginas actuales lo empeoran al tener muchos nombres de host. Las tipografías, la analítica, las imágenes y los widgets de pago necesitan cada uno su propia consulta, y un navegador que resuelve diez nombres de host a 300 ms cada uno ha gastado tres segundos en DNS antes de dibujar nada útil.

Confirma que el DNS es la parte lenta

Mide antes de cambiar nada. El comando más limpio divide una petición en sus fases:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Si time_namelookup es una fracción pequeña del total, el DNS no es tu problema y lo que deberías estar leyendo es sobre el tiempo de respuesta del servidor. Si es un tercio o más, sigue adelante. Para la consulta por su cuenta, dig imprime el tiempo transcurrido:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

En Windows, PowerShell da la misma lectura:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Compara tu resolutor por defecto con los públicos. Una diferencia grande te dice que la solución está en tu lado. Tiempos parecidos en todas partes apuntan a los servidores de nombres del propio dominio.

Un resultado descarta esta guía por completo. Si un resolutor responde al instante con NXDOMAIN, el nombre no está publicado y tienes otro problema distinto, descrito en DNS_PROBE_FINISHED_NXDOMAIN.

Por qué ocurre

• Un resolutor lejano. Los servicios públicos usan anycast, así que la misma dirección responde desde una ubicación cercana. El resolutor de un proveedor de internet o un único servidor de oficina no lo hacen, y cada consulta paga el viaje completo.
• El primer servidor de la lista está muerto. El cliente espera a que venza su tiempo límite y luego pregunta al segundo. En sistemas con glibc el valor por defecto son 5 segundos antes del primer reintento, que es exactamente la pausa que la gente describe como "se queda colgado y luego carga".
• TTL muy bajos. Un TTL de 30 o 60 segundos hace que casi todos los visitantes paguen una consulta nueva, porque la copia en caché ya ha caducado.
• Cadenas CNAME largas. Cada eslabón es otra consulta. Las cadenas de tres o cuatro son habituales detrás de las CDN y las herramientas de marketing.
• Servidores de nombres autoritativos lentos. Un proveedor de DNS con pocas ubicaciones responde rápido a una parte del mundo y despacio al resto.
• Validación DNSSEC. Validar una cadena añade consultas. Normalmente es barato, pero una cadena parcialmente rota provoca reintentos que parecen lentitud.
• Dominios de búsqueda. Un resolutor configurado con sufijos prueba example.com.corp.local antes que example.com, y gasta una consulta fallida en cada sufijo primero.
• Consultas AAAA sin IPv6. El sistema pide los dos tipos de registro y espera una respuesta que no puede usar.
• Una VPN o un proxy de filtrado que envía cada consulta por un túnel hasta un resolutor en otro continente.
• Un router haciendo de reenviador con una caché diminuta y una CPU insuficiente.

Cómo solucionarlo

En tu dispositivo

1. Vacía las cachés para que tus mediciones sean honestas: ipconfig /flushdns en Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en macOS, sudo resolvectl flush-caches en Linux.
2. Mira qué servidores están configurados y en qué orden: Get-DnsClientServerAddress, scutil --dns o resolvectl status. Elimina cualquier entrada que ya no responda, porque una primera entrada muerta te cuesta el tiempo límite en cada consulta en frío.
3. En Linux, acorta la espera mientras investigas añadiendo options timeout:2 attempts:2 a /etc/resolv.conf, y recorta los sufijos search que no uses.
4. Desconecta la VPN y mide otra vez. Si el número baja a la mitad, la causa es el túnel y lo que hay que cambiar es su resolutor.

En tu red

1. Configura el resolutor en el DHCP del router en lugar de dispositivo por dispositivo, para que todos los clientes reciban el mismo par rápido.
2. Dale al reenviador del router un resolutor público aguas arriba en vez del que trae el proveedor, o sáltate el reenviador por completo entregando las direcciones públicas directamente a los clientes.
3. En una red corporativa con su propio servidor DNS, comprueba que reenvía en lugar de hacer recursión completa desde un solo sitio, y que su caché es lo bastante grande para aguantar la jornada.

En tu propio dominio

1. Sube los TTL de los registros que casi nunca cambian. Cinco minutos es un suelo razonable para un registro que quizá tengas que mover deprisa; una hora o un día encaja con todo lo estable.
2. Aplana las cadenas CNAME donde puedas. Apunta el registro al destino final en lugar de a una cadena de alias: dig www.example.com CNAME +short muestra cuánto se alarga la tuya.
3. Usa un proveedor de DNS con servidores de nombres anycast, y mantén al menos dos servidores de nombres en redes distintas.
4. Comprueba que DNSSEC valida. Compara una consulta normal con otra que se salte la validación: dig example.com @1.1.1.1 frente a dig +cd example.com @1.1.1.1. Una diferencia grande, o un SERVFAIL solo en la primera, significa que la cadena está rota.

Verifícalo desde fuera

Tus propios tiempos describen una red en un momento, que es la muestra menos útil que puedes tomar. Un resolutor que está a 8 ms de ti puede estar a 400 ms de un cliente de otra región, y ese cliente es el que se queja.

Empieza midiendo los servidores autoritativos directamente, lo que elimina todas las cachés entre tú y la fuente:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

La salida de +trace recorre la delegación paso a paso, así que un salto que se atasca se ve en lugar de diluirse en una media. Después ejecuta la verificación de consulta DNS, que resuelve el nombre desde puntos de verificación en distintos países e informa de cada uno por separado. Esa es la medición que no puedes hacer desde un portátil: muestra si tus servidores de nombres son lentos en todas partes, lo que apunta al proveedor, o lentos desde un continente, lo que apunta a su cobertura de red. Si algunas ubicaciones devuelven una respuesta distinta en lugar de una más lenta, la pregunta pasa a ser de propagación, tratada en cómo comprobar la propagación DNS.

Latencia que se va desviando en vez de romperse

La latencia de DNS rara vez se rompe de forma evidente. Se va desviando: un servidor de nombres pierde una ubicación, un TTL se baja durante una migración y nunca se vuelve a subir, y seis semanas después el sitio va pesado por razones que nadie sabe señalar. Una única medición no puede mostrar una tendencia, y por eso vale la pena registrar el tiempo de consulta de forma programada desde las regiones donde están tus visitantes. HostTracker monitorea sitios web desde 2004 y hoy vigila más de 500.000 sitios desde puntos de verificación en 158 ciudades, guardando el historial que hace visible una desviación lenta. Las demás guías están en el grupo de soluciones, y el caso en el que no vuelve nada en absoluto es el servidor DNS no responde.