¿Por qué la latencia del DNS hace que una aplicación de servidor doméstico se sienta lenta en una red LAN?

Una aplicación de servidor doméstico puede sentirse lenta en una LAN rápida porque el cliente puede tener que resolver su nombre de host antes de poder iniciar una conexión nueva. Si esa búsqueda espera en una caché vacía, un resolvedor no disponible o una ruta de reserva, la pausa ocurre antes de que la aplicación tenga oportunidad de responder.

Esto no significa que DNS se ejecute antes de cada solicitud HTTP ni que reduzca el rendimiento de una conexión establecida. DNS es más visible cuando un cliente necesita un resultado de dirección nuevo o una conexión nueva, por eso la primera carga puede sentirse lenta mientras que la navegación posterior se siente normal.

La latencia DNS retrasa el inicio de la conexión, no cada solicitud de la aplicación

Cuando un navegador o cliente abre un nombre de host, su resolvedor debe devolver una dirección que la pila de red pueda usar. El modelo de resolvedor DNS permite que esa respuesta provenga de información en caché o de uno o más servidores de nombres, por lo que el tiempo de búsqueda puede variar incluso cuando el servidor de destino nunca cambia.

Una vez que una dirección y conexión están disponibles, las solicitudes posteriores pueden reutilizarlas. HTTP/2, por ejemplo, asocia los intercambios de solicitud y respuesta con flujos independientes en una conexión; esta multiplexación de flujos HTTP/2 es una razón por la que muchos recursos no requieren una conexión nueva ni una búsqueda DNS por separado.

Una LAN facilita notar el contraste. La transferencia de datos y los viajes de ida y vuelta al servidor pueden ser breves, mientras que un reintento o ruta de reserva del resolvedor sigue siendo una espera separada antes que ellos. El usuario experimenta el tiempo combinado y puede culpar a la aplicación, al almacenamiento o a la red aunque la demora haya ocurrido antes de que comenzara el tráfico de la aplicación.

Cómo se resuelve un nombre de host de servidor doméstico en una LAN

Cachés del navegador y del sistema operativo

El cliente puede ya tener un resultado de dirección utilizable. Un acierto en caché puede eliminar la necesidad de un intercambio DNS en la red, mientras que una entrada expirada o ausente envía la solicitud más lejos en la ruta de resolución. Las cachés del navegador, del sistema operativo y del resolvedor recursivo son capas separadas, por lo que su estado no siempre cambia al mismo tiempo.

El resolvedor LAN configurado

Cuando no hay datos de caché local disponibles, un cliente comúnmente consulta a un resolvedor configurado, que puede ser un router, un servicio DNS local dedicado u otro resolvedor recursivo. Ese resolvedor puede responder desde una zona local autorizada, desde su propia caché o buscar la consulta en otro lugar. Que el servidor esté en la LAN no garantiza que todos los resolvedores involucrados estén igualmente cerca o funcionen correctamente.

Dominios de búsqueda, mDNS y rutas de reserva

Los nombres de host cortos y los nombres que terminan en .local pueden seguir mecanismos diferentes. Las reglas multicast DNS para nombres .local dirigen esas consultas al multicast de enlace local, mientras que las implementaciones también pueden usar otros mecanismos simultáneamente. Los sufijos de búsqueda y el comportamiento de reserva pueden añadir intentos que las descripciones ordinarias de DNS unicast no capturan.

Los fallos de caché y los tiempos de espera del resolutor producen pausas diferentes

Un fallo de caché no es automáticamente un error. Significa que la respuesta debe obtenerse de otra fuente, por lo que la primera búsqueda puede tardar más que una búsqueda en caché. Un tiempo de espera es diferente: el resolutor no recibió una respuesta útil dentro de su período de espera y puede reintentar con otro servidor o transporte.

La guía actual sobre fallos y reintentos DNS distingue fallos, servidores inaccesibles, reintentos y fallos en caché. También señala que preguntas idénticas pendientes pueden combinarse en lugar de emitirse como consultas ascendentes independientes, por lo que los retrasos DNS no deben multiplicarse mecánicamente por el número de recursos de la aplicación.

El patrón visible suele ser más informativo que un promedio único. Un retraso consistentemente pequeño en la primera carga, un retraso por caché fría y una pausa larga irregular apuntan a estados diferentes y no deben agruparse bajo una etiqueta genérica de “DNS lento”.

Una pantalla de aplicación puede involucrar varios nombres de host

Un panel local puede cargar su documento principal desde un nombre de host mientras contacta otros nombres para una API, punto final WebSocket, servicio de identidad, complemento, fuente, imagen de portada o verificación de actualización. Solo la aplicación principal debe ser local para que la pantalla parezca local; su gráfico de dependencias aún puede cruzar varios orígenes.

Cada nuevo origen puede crear otra oportunidad de resolución y conexión, pero los retrasos no necesariamente se suman en línea recta. Los navegadores pueden emitir trabajos simultáneamente, los resolutores pueden almacenar en caché o combinar preguntas coincidentes, y múltiples recursos del mismo origen pueden compartir una conexión.

La pregunta práctica no es “¿Cuántos archivos hay en la página?” sino “¿Cuántos nombres distintos y nuevas rutas de conexión se requieren antes de que la interfaz sea usable?” Una pequeña dependencia de API bloqueante puede importar más que muchas imágenes cargadas después en paralelo.

Por qué la primera carga puede ser lenta pero las actualizaciones se sienten rápidas

La primera visita puede incluir una búsqueda DNS, una nueva conexión TCP, un apretón de manos TLS, autenticación y trabajo inicial de la aplicación. Una actualización puede beneficiarse de cachés de direcciones, conexiones existentes, entradas de caché HTTP y datos de aplicación calentados al mismo tiempo.

Eso hace que una actualización más rápida sea una pista útil, no una prueba de que DNS fue la única causa. Para aislar DNS, la fase de búsqueda debe separarse del establecimiento de la conexión y la respuesta del servidor en lugar de tratar la diferencia completa de la primera carga como tiempo del resolvedor.

La ubicación del resolvedor importa más cuando el nombre es local

Un nombre de host interno necesita un mecanismo de resolución que entienda su espacio de nombres. Una zona autorizada local, un arreglo de DNS dividido o un nombre mDNS pueden mantener la respuesta asociada con la LAN, mientras que un resolvedor público general puede no tener registro para ese nombre interno.

Esto no significa que cada nombre de host local enviado a un resolvedor externo haga un viaje lento y eventualmente tenga éxito. Dependiendo del nombre y la configuración, el resultado puede ser una respuesta negativa rápida, un reintento o una caída a otro mecanismo. La ubicación del resolvedor importa porque cambia qué sistema puede responder correctamente, no simplemente porque un servidor esté físicamente más cerca.

DNS no es la única fuente de una primera respuesta lenta

El inicio de la aplicación, las consultas a la base de datos, la E/S de almacenamiento, el enrutamiento del proxy inverso, la autenticación y TLS pueden retrasar la primera respuesta visible después de que la resolución del nombre haya terminado. Si el nombre de host y una prueba controlada basada en direcciones son igualmente lentos, el cuello de botella es menos probable que sea DNS.

Una comparación basada en direcciones también tiene límites. Los certificados HTTPS y el alojamiento virtual dependen de los nombres, y un proxy inverso puede enrutar la misma IP a diferentes aplicaciones según el nombre de host solicitado. Una prueba de dirección fallida o con comportamiento diferente no es un punto de referencia limpio para DNS.

Use el límite de síntomas con cuidado: DNS es plausible cuando las esperas se agrupan alrededor del uso de nombres no almacenados en caché, fallos del resolvedor o nuevas rutas de conexión. Es menos plausible cuando el tiempo de búsqueda es insignificante pero el tiempo hasta el primer byte sigue siendo alto.

Separe el tiempo DNS del tiempo TCP, TLS y de la aplicación

La cadena útil de latencia es la búsqueda DNS, la configuración de la conexión, la configuración de la conexión segura cuando sea aplicable, el inicio de la solicitud, el inicio de la respuesta y la transferencia de contenido. El modelo de fases de navegación W3C expone marcas de tiempo separadas para la búsqueda de dominio y la conexión, incluyendo el caso en que la información del dominio proviene de la caché.

Para recursos individuales de página, la interfaz Resource Timing separa las fases de búsqueda, conexión, solicitud y respuesta. Las reglas de privacidad entre orígenes pueden ocultar algunos detalles, por lo que los campos de tiempo faltantes no son automáticamente evidencia de latencia cero.

El ping y el rendimiento de copia de archivos responden a preguntas diferentes. El ping mide la accesibilidad y el comportamiento de ida y vuelta de la red; una transferencia grande mide una ruta de datos establecida. Ninguno aísla la resolución de nombres que puede ocurrir antes de que una aplicación abra su primera conexión.

Preguntas frecuentes

¿Afecta el DNS a cada clic dentro de una aplicación de servidor doméstico?

No. DNS importa cuando el cliente necesita resolver un nombre para un resultado nuevo o expirado. Las direcciones en caché, las conexiones persistentes y las solicitudes multiplexadas pueden permitir que muchas interacciones procedan sin una consulta DNS de red fresca.

¿Por qué la aplicación carga más rápido por dirección IP que por nombre de host?

Omitir el nombre de host puede eliminar la resolución de nombres de esa ruta de prueba, por lo que la diferencia puede implicar DNS. No es concluyente porque los certificados, hosts virtuales, redireccionamientos y reglas de proxy inverso pueden hacer que la ruta de la dirección se comporte de manera diferente.

¿Puede mDNS ser más lento que el DNS local regular?

Puede comportarse de manera diferente porque usa multidifusión local de enlace y puede coexistir con otros mecanismos de búsqueda. Si es más lento depende del cliente, la red, el nombre, el almacenamiento en caché y el comportamiento de reserva, no de una penalización universal de mDNS.

¿Cambiar el DNS público acelerará el nombre de un servidor doméstico local?

Solo si ese resolvedor público es realmente parte de la ruta exitosa o fallida. Un nombre almacenado en una zona local o resuelto a través de mDNS necesita el mecanismo local apropiado; cambiar un resolvedor público no relacionado puede no hacer nada.

¿Por qué la aplicación se vuelve lenta nuevamente después de un reinicio o un largo período de inactividad?

Un reinicio o un período largo de inactividad pueden eliminar datos de direcciones en caché y cerrar conexiones reutilizables, mientras que la propia aplicación también puede perder cachés calentados. Por lo tanto, la siguiente carga puede repetir varias etapas de inicio, no solo DNS.

Los cambios en DNS afectan el tiempo de inicio de la aplicación, no el rendimiento del NAS doméstico

La resolución de nombres confiable y de baja latencia puede hacer que las primeras conexiones y las nuevas dependencias de la aplicación se sientan más rápidas, pero no aumenta la velocidad del disco ni el rendimiento de una transferencia LAN establecida. Diagnostique DNS en su lugar antes de que comience la conexión, luego mida TCP, TLS y la respuesta de la aplicación por separado antes de culpar al servidor doméstico.