Introducción: Causas y mitigaciones de la latencia de DNS
A medida que las páginas web se vuelven más complejas y hacen referencia a recursos de varios 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 por 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 deba consultar (más de 2 es poco frecuente, pero puede suceder). A modo de ejemplo, en la siguiente captura de pantalla, se muestran los tiempos que informa la herramienta de medición del rendimiento web Velocidad de la página. Cada barra representa un recurso al que se hace referencia en la página; los segmentos negros indican las búsquedas de DNS. En esta página, se realizan 13 búsquedas en los primeros 11 segundos en los que se carga la página. Aunque varias de las búsquedas se realizan en paralelo, la captura de pantalla muestra que se requieren 5 tiempos de búsqueda en serie, lo que representa varios segundos del tiempo total de carga de la página de 11 segundos.
La latencia de DNS tiene dos componentes:
- La 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 parte, a las restricciones habituales de tiempo de ida y vuelta (RTT) en los sistemas conectados en red: distancia geográfica entre las máquinas del cliente y del servidor; congestión de la red; pérdida de paquetes y retrasos prolongados de retransmisión (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 están geográficamente remotos.
- Aprovisionamiento insuficiente. 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 de DNS está aprovisionado en exceso, el tráfico DoS puede colocar una carga indebida en los servidores. De manera similar, los ataques estilo Kaminsky pueden implicar el desbordamiento de agentes de resolución con consultas que garantizan el paso de la caché y requieren solicitudes salientes para su resolución.
Creemos que el factor de error de caché es la causa dominante de la latencia de DNS, por lo que lo analizaremos a continuación.
Errores de caché
Incluso si un agente de resolución tiene una gran cantidad de recursos locales, las demoras fundamentales asociadas con la comunicación con servidores de nombres remotos son difíciles de evitar. En otras palabras, suponiendo que el agente de resolución se aprovisione lo suficientemente bien como para que los aciertos de caché tarden 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. Con la operación del rastreador web de Googlebot, observamos un tiempo de resolución promedio de 130 ms para los servidores de nombres que responden. Sin embargo, entre el 4% y el 6% de las solicitudes simplemente se agota el tiempo de espera, debido a la pérdida de paquetes UDP y a los servidores inaccesibles. Si tenemos en cuenta 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 variación y una cola larga.
Aunque la tasa de errores de caché puede variar entre los servidores DNS, es muy difícil evitarlos por los siguientes motivos:
- Tamaño y crecimiento de Internet En pocas palabras, a medida que Internet crece, tanto mediante la adición de nuevos usuarios como de sitios nuevos, la mayor parte del contenido es de interés marginal. Si bien algunos sitios (y, en consecuencia, los nombres de DNS) son muy populares, la mayoría son de interés para unos pocos usuarios y se accede muy pocas veces. Por lo tanto, 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 balanceadores de cargas que asignan consultas a diferentes máquinas de forma aleatoria. Como resultado, cada servidor individual mantiene 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ándar; otros son experimentales:
- Aprovisionar servidores de forma adecuada para controlar la carga del tráfico de clientes, incluido el tráfico malicioso.
- Prevención de ataques de DoS y amplificación Aunque, en su mayoría, se trata de un problema de seguridad y afecta a los agentes de resolución cerrados menos que a los abiertos, prevenir los ataques DoS también tiene un beneficio para el rendimiento, ya que se elimina la carga de tráfico adicional que se genera en los servidores DNS. Si quieres obtener información sobre los enfoques que usamos para minimizar las posibilidades de ataques, consulta la página sobre 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
- Brinda cobertura global para brindar proximidad a todos los usuarios.
Aprovisiona clústeres de entrega de forma adecuada
Los agentes de resolución de DNS de almacenamiento 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 cambio, requieren comunicación con otros servidores de nombres y, por lo tanto, exigen una gran cantidad de entrada y salida de red. Además, los agentes de resolución abiertos son muy vulnerables a los intentos de envenenamiento de la caché, lo que aumenta la tasa de errores de caché (estos ataques envían específicamente solicitudes de nombres falsos que no se pueden resolver desde la caché) y a los ataques DoS, que se agregan 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 volver a transmitirse, las solicitudes del servidor de nombres deben estar en cola, etcétera. Todos estos factores aumentan las demoras.
Por lo tanto, es importante que los agentes de resolución de DNS se aprovisionen para las entradas y salidas de gran volumen. Esto incluye controlar posibles ataques de DDoS, para lo 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 implementar una política eficaz de balanceo de cargas, 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 adición de máquinas puede generar un impacto contraproducente 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 ubican detrás de un balanceador de cargas que distribuye de forma 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é quede aislado en todas 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 se puede aumentar de forma proporcional. Por ejemplo, para los nombres con TTL largos que se consultan repetidamente, la tasa de errores de caché se puede aumentar según la cantidad de máquinas en el clúster. (En el caso de 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 errores de caché no se ve realmente afectada cuando se agregan 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 se fragmente. 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 no se puede satisfacer una consulta desde esta caché, se envía a otro grupo de máquinas que particionan la caché por nombres. Para esta caché de segundo nivel, todas las consultas con el mismo nombre se envían a la misma máquina, donde el nombre está almacenado en caché o no.
Distribución de clústeres de servicio para una amplia cobertura geográfica
En el caso de los agentes de resolución cerrados, esto no es realmente un problema. Para los agentes de resolución abiertos, cuanto más cerca estén los servidores de los usuarios, menor será la latencia que verán en el extremo del cliente. Además, tener una cobertura geográfica suficiente puede mejorar indirectamente 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 se aloja 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 la ubicación geográfica.
Además, el DNS público de Google admite la subred de cliente (ECS) de EDNS, una extensión del protocolo DNS que permite que los agentes de resolución reenvíen la ubicación del cliente a los servidores de nombres, lo que puede mostrar respuestas sensibles a la ubicación optimizadas para la dirección IP real del cliente, en lugar de la dirección IP del agente de resolución. Lee estas Preguntas frecuentes para obtener más detalles. El DNS público de Google detecta de forma automática los servidores de nombres compatibles con la subred de cliente de EDNS.