Introducción: Causas y mitigaciones de la latencia de DNS
A medida que las páginas web se vuelven más complejas, hacen referencia a recursos de numerosos dominios. Las búsquedas de DNS pueden convertirse en un cuello de botella significativo en la experiencia de navegación. Cada vez que un cliente necesita consultar un agente de resolución de DNS a través de la red, la latencia ingresada puede ser significativa, según la proximidad y la cantidad de servidores de nombres que el agente de resolución debe consultar (más de 2 es poco frecuente, pero puede suceder). A modo de ejemplo, la siguiente captura de pantalla muestra los tiempos informados por la herramienta de medición del rendimiento web Page Speed. Cada barra representa un recurso al que se hace referencia en la página; los segmentos negros indican búsquedas de DNS. En esta página, se realizan 13 búsquedas en los primeros 11 segundos en los que se carga. Si bien varias de las búsquedas se realizan en paralelo, la captura de pantalla muestra que se requieren 5 tiempos de búsqueda en serie, que representan varios segundos del tiempo total de carga de la página de 11 segundos.
La latencia del DNS tiene dos componentes:
- Latencia entre el cliente (usuario) y el servidor de resolución de DNS En la mayoría de los casos, esto se debe, en gran medida, a las restricciones habituales del tiempo de ida y vuelta (RTT) en los sistemas en red: distancia geográfica entre las máquinas del cliente y del servidor; congestión en la red; pérdida de paquetes y demoras prolongadas en los retransmisiones (un segundo en promedio), servidores sobrecargados, ataques de denegación del servicio, etcétera.
- Latencia entre la resolución de servidores y otros servidores de nombres.
Esta fuente de latencia se debe principalmente a los siguientes factores:
- Errores de caché. Si una respuesta no se puede entregar desde la caché de un agente de resolución, pero requiere consultar de manera recurrente otros servidores de nombres, la latencia de red agregada es considerable, en especial si los servidores autorizados son remotos geográficamente.
- Bajo aprovisionamiento. Si los agentes de resolución de DNS están sobrecargados, deben poner en cola las solicitudes y respuestas de resolución de DNS, y pueden comenzar a descartar y retransmitir paquetes.
- Tráfico malicioso Incluso si un servicio DNS está aprovisionado en exceso, el tráfico DoS puede colocar una carga indebida en los servidores. De manera similar, los ataques de estilo Kaminsky pueden incluir agentes de resolución de inundación con consultas que garantizan la omisión de la caché y requieren solicitudes salientes para su resolución.
Creemos que el factor de error de caché es la causa más dominante de latencia de DNS, y lo analizaremos con más detalle a continuación.
Errores de caché
Incluso si un agente de resolución tiene abundantes recursos locales, es difícil evitar las demoras fundamentales asociadas con la comunicación con servidores de nombres remotos. En otras palabras, suponiendo que el agente de resolución está aprovisionado de forma correcta, por lo que los aciertos de caché tardan cero en el servidor, los errores de caché siguen siendo muy costosos en términos de latencia. Para manejar un error, un agente de resolución debe comunicarse con al menos uno, pero a menudo dos o más servidores de nombres externos. Al operar el rastreador web de Googlebot, observamos un tiempo de resolución promedio de 130 ms para los servidores de nombres que responden. Sin embargo, se agota el tiempo de espera de un 4% a un 6% debido a la pérdida de paquetes de UDP y a que no se puede acceder a los servidores. Si tenemos en cuenta las fallas, como la pérdida de paquetes, los servidores de nombres muertos, los errores de configuración de DNS, etc., el tiempo de resolución promedio real de extremo a extremo es de 300 a 400 ms. Sin embargo, hay una gran varianza y una cola larga.
Aunque la tasa de errores de caché puede variar entre los servidores DNS, es difícil evitar los errores de caché por los siguientes motivos:
- Crecimiento y tamaño de Internet En pocas palabras, a medida que Internet crece, tanto a través de la incorporación de usuarios nuevos como de sitios nuevos, la mayor parte del contenido es de interés marginal. Si bien algunos sitios (y, en consecuencia, nombres de DNS) son muy populares, la mayoría son de interés para solo unos pocos usuarios y se accede a ellos con poca frecuencia, por lo que la mayoría de las solicitudes generan errores de caché.
- Valores de tiempo de actividad (TTL) bajos. La tendencia hacia valores de TTL de DNS más bajos significa que las resoluciones necesitan búsquedas más frecuentes.
- Aislamiento de caché. Por lo general, los servidores DNS se implementan detrás de los balanceadores de cargas que asignan consultas a diferentes máquinas de forma aleatoria. Esto hace que cada servidor individual mantenga una caché separada en lugar de poder reutilizar las resoluciones almacenadas en caché de un grupo compartido.
Mitigaciones
En el DNS público de Google, implementamos varios enfoques para acelerar los tiempos de búsqueda de DNS. Algunos de estos enfoques son bastante estándares; otros son experimentales:
- Aprovisionar servidores de manera adecuada para manejar la carga del tráfico del cliente, incluido el tráfico malicioso
- Prevención de ataques de DoS y amplificación Aunque esto es un problema de seguridad y afecta a los agentes de resolución cerrados menos que los abiertos, evitar los ataques de DoS también es beneficioso para el rendimiento, ya que elimina la carga de tráfico adicional que se coloca en los servidores DNS. Si deseas obtener información sobre los enfoques que usamos para minimizar las probabilidades de sufrir ataques, consulta la página sobre los beneficios de seguridad.
- Balanceo de cargas para el almacenamiento en caché compartido, a fin de mejorar la tasa de aciertos de caché agregada en el clúster de entrega.
- Brindar cobertura global a fin de brindar proximidad a todos los usuarios.
Aprovisiona los clústeres de forma adecuada
Los agentes de resolución de DNS en caché deben realizar operaciones más costosas que los servidores de nombres autorizados, ya que muchas respuestas no se pueden entregar desde la memoria; en su lugar, requieren comunicación con otros servidores de nombres y, por lo tanto, exigen mucha entrada y salida en la red. Además, los agentes de resolución abiertos son muy vulnerables a los intentos de envenenamiento de la caché, que aumentan la tasa de errores de caché (dichos ataques envían específicamente solicitudes de nombres falsos que no se pueden resolver desde la caché) y a ataques de DoS, que se suman a la carga de tráfico. Si los agentes de resolución no se aprovisionan de forma adecuada y no pueden seguir el ritmo de la carga, esto puede tener un impacto muy negativo en el rendimiento. Los paquetes se descartan y deben retransmitirse, las solicitudes del servidor de nombres deben estar en cola, etcétera. Todos estos factores generan demoras.
Por lo tanto, es importante que los agentes de resolución de DNS se aprovisionen para entradas y salidas de gran volumen. Esto incluye el manejo de posibles ataques de DSD, para los que la única solución eficaz es aprovisionar en exceso con muchas máquinas. Sin embargo, al mismo tiempo, es importante no reducir la tasa de aciertos de caché cuando agregas máquinas; esto requiere la implementación de una política de balanceo de cargas efectiva, que se analiza a continuación.
Balanceo de cargas para el almacenamiento en caché compartido
El escalamiento de la infraestructura del agente de resolución mediante la incorporación de máquinas puede tener consecuencias negativas y reducir la tasa de aciertos de caché si el balanceo de cargas no se realiza de forma correcta. En una implementación típica, varias máquinas se encuentran detrás de un balanceador de cargas que distribuye de manera equitativa el tráfico a cada máquina, mediante un algoritmo simple como round robin. El resultado de esto es que cada máquina mantiene su propia caché independiente, de modo que el contenido almacenado en caché se aísla entre las máquinas. Si cada consulta entrante se distribuye a una máquina aleatoria, según la naturaleza del tráfico, la tasa de errores de caché efectiva puede aumentar de forma proporcional. Por ejemplo, para los nombres con TTL largos que se consultan de forma repetida, la tasa de errores de caché puede aumentar por la cantidad de máquinas en el clúster. (Para los nombres con TTL muy cortos, que se consultan con muy poca frecuencia o que generan respuestas que no se pueden almacenar en caché (0 TTL y errores), la tasa de error de caché no se ve realmente afectada por la adición de máquinas).
Para aumentar la tasa de aciertos de los nombres que pueden almacenarse en caché, es importante balancear las cargas de los servidores a fin de que la caché no esté fragmentada. En el DNS público de Google, tenemos dos niveles de almacenamiento en caché. En un grupo de máquinas, muy cerca del usuario, una pequeña caché por máquina contiene los nombres más populares. Si una consulta no se puede satisfacer desde esta caché, se envía a otro grupo de máquinas que dividen la caché por nombres. Para esta caché de segundo nivel, todas las consultas para el mismo nombre se envían a la misma máquina, en la que el nombre se almacena en caché o no.
Distribución de clústeres de entrega para una amplia cobertura geográfica
Para los agentes de resolución cerrados, esto no es realmente un problema. En el caso de los agentes de resolución abiertos, cuanto más cerca estén los servidores de los usuarios, menos latencia verán en el extremo del cliente. Además, tener suficiente cobertura geográfica puede mejorar de forma indirecta la latencia de extremo a extremo, ya que los servidores de nombres suelen mostrar resultados optimizados para la ubicación del agente de resolución de DNS. Es decir, si un proveedor de contenido aloja sitios duplicados en todo el mundo, los servidores de nombres de ese proveedor mostrarán la dirección IP más cercana al agente de resolución de DNS.
El DNS público de Google está alojado en centros de datos en todo el mundo y usa el enrutamiento anycast para enviar a los usuarios al centro de datos más cercano a nivel geográfico.
Además, el DNS público de Google admite la subred de cliente de EDNS (ECS), una extensión de protocolo de DNS para que los agentes de resolución reenvíen la ubicación del cliente a los servidores de nombres, que pueden mostrar respuestas sensibles a la ubicación optimizadas para la dirección IP de cliente real, en lugar de la dirección IP del agente de resolución. Lee estas Preguntas frecuentes para obtener más información. El DNS público de Google detecta automáticamente los servidores de nombres que admiten la subred de cliente EDNS.