La latencia del Sistema de Nombres de dominio (DNS) es un componente clave para tener una buena experiencia en línea. Y para minimizar la latencia de DNS, elegir cuidadosamente los servidores DNS y los relés de anonimización juega un papel importante.
Pero la mejor manera de minimizar la latencia es evitar el envío de consultas inútiles para empezar. Es por eso que el DNS fue diseñado, desde el primer día, para ser un protocolo altamente cacheable. Los registros individuales tienen un tiempo de vida (TTL), establecido originalmente por los administradores de zona, y los resolutores usan esta información para mantener estos registros en memoria para evitar tráfico innecesario.
¿El almacenamiento en caché es eficiente? Un estudio rápido que hice hace un par de años mostró que había margen de mejora. Hoy quiero dar un nuevo vistazo a la situación actual.
Para ello, parcheé un servidor DNS cifrado para almacenar el TTL original de una respuesta, definido como el TTL mínimo de sus registros, para cada consulta entrante. Esto nos da una buena visión general de la distribución TTL del tráfico del mundo real, pero también explica la popularidad de las consultas individuales.
Esa versión parcheada se dejó ejecutar durante un par de horas. El conjunto de datos resultante se compone de 1.583.579 tuplas (nombre, qtype, TTL, marca de tiempo). Aquí está la distribución general de TTL (el eje X es el TTL en segundos):
Además de un bache insignificante en 86,400 (principalmente para registros SOA), es bastante obvio que las TTL están en el rango bajo. Ampliemos:
Bien, las TTL superiores a 1 hora son estadísticamente insignificantes. Centrémonos en el rango 0-3,600:
Y donde la mayoría de TTL se encuentran entre 0 y 15 minutos:
La gran mayoría se encuentra entre 0 y 5 minutos:
Esto no es genial. La distribución acumulativa puede hacer que el problema sea aún más obvio:
La mitad de Internet tiene un TTL de 1 minuto o menos, y tres cuartas partes tienen un TTL de 5 minutos o menos.
Pero espera, esto es en realidad peor. Estos son TTL definidos por servidores autoritativos. Sin embargo, las TTL recuperadas de los resolutores de cliente (por ejemplo, enrutadores, cachés locales) obtienen un TTL que los resolutores ascendentes disminuyen cada segundo. Por lo tanto, en promedio, la duración real que un cliente puede usar una entrada en caché antes de requerir una nueva consulta es la mitad del TTL original.
Puede que estas TTL muy bajas solo afecten a consultas poco comunes, y no a sitios web y API populares. Echemos un vistazo:
Desafortunadamente, las consultas más populares también son las más inútiles para almacenar en caché. Ampliemos:
Veredicto: es realmente malo, o más bien ya era malo, y ha empeorado. El almacenamiento en caché de DNS se ha vuelto casi inútil. Con menos personas que usan el solucionador de DNS de su ISP (por buenas razones), el aumento de la latencia se hace más notable. El almacenamiento en caché de DNS se ha vuelto útil solo para el contenido que nadie visita. Además, tenga en cuenta que el software puede interpretar TTL bajos de manera diferente.
¿Por qué?
¿Por qué se establecen registros DNS con TTL tan bajos?
- Los equilibradores de carga heredados se dejan con la configuración predeterminada.
- La leyenda urbana de que el equilibrio de carga basado en DNS depende de TTLs (no lo hace).
- Los administradores desean que sus cambios se apliquen de inmediato, ya que puede requerir menos trabajo de planificación.
- Como administrador de DNS o equilibrador de carga, su deber es implementar de manera eficiente la configuración que la gente pide, no hacer que los sitios web y los servicios sean rápidos.
- Los TTL bajos dan tranquilidad.
No estoy incluyendo ‘para conmutación por error’ en esa lista, ya que esto se ha vuelto cada vez menos relevante. Si la intención es redirigir a los usuarios a una red diferente solo para mostrar una página de ballena fallida cuando absolutamente todo lo demás está en llamas, tener más de un minuto de retraso es probablemente aceptable.
Las CDN y los equilibradores de carga son en gran parte culpables, especialmente cuando combinan registros CNAME con TTL cortos con registros que también tienen TTL cortos (pero independientes):
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
Se debe enviar una nueva consulta cada vez que caduque el CNAME o cualquiera de los registros A. Ambos tienen un TTL de 30 segundos, pero no están en fase. El TTL promedio real será de 15 segundos.
Pero espera! Esto es peor. Algunos resolutores se comportan bastante mal en una situación de registro de TTL-CNAME bajo+TTL bajo:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Este es el solucionador de Level3, que, creo, está ejecutando BIND. Si sigue enviando esa consulta, el TTL devuelto siempre será 1. Esencialmente, raw.githubusercontent.com nunca se almacenará en caché.
Este es otro ejemplo de una situación de registro de TTL-CNAME bajo + TTL bajo, con un nombre muy popular:
$ drill detectportal.firefox.com @1.1.1.1detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net.detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net.detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net.a1089.dscd.akamai.net. 10 IN A 104.123.50.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
No menos de tres registros CNAME. Ouch. Uno de ellos tiene un TTL decente, pero es totalmente inútil. Otros CNAMEs tienen un TTL original de 60 segundos; el akamai.net los nombres tienen un TTL máximo de 20 segundos y nada de eso está en fase.
¿Qué tal uno que tus dispositivos Apple sondeen constantemente?
$ drill 1-courier.push.apple.com @4.2.2.21-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net.1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net.gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
La misma configuración que Firefox y el TTL está pegada a 1 la mayor parte del tiempo cuando se usa el solucionador de Level3.
¿Qué pasa con Dropbox?
$ drill client.dropbox.com @8.8.8.8client.dropbox.com. 7 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 59 IN A 162.125.67.3$ drill client.dropbox.com @4.2.2.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com tiene un TTL de 60 segundos. Los nombres de Facebook tienen un TTL de 60 segundos. Y, una vez más, desde la perspectiva del cliente, estos valores deben reducirse a la mitad.
¿Qué tal establecer un TTL mínimo?
Usando el nombre, el tipo de consulta, el TTL y la marca de tiempo almacenados inicialmente, escribí un script que simula los más de 1,5 millones de consultas que pasan por un solucionador de caché para estimar cuántas consultas se enviaron debido a una entrada de caché caducada. el 47,4% de las consultas se realizaron después de que una entrada en caché existente hubiera expirado. Esto es irrazonablemente alto.
¿Cuál sería el impacto en el almacenamiento en caché si se estableciera un TTL mínimo?
El eje X es el TTL mínimo establecido. Los registros cuyo TTL original era superior a este valor no se vieron afectados. El eje Y es el porcentaje de consultas realizadas por un cliente que ya tenía una entrada en caché, pero se realizó una nueva consulta y la entrada en caché había caducado.
El número de consultas se reduce del 47% al 36% con solo establecer un TTL mínimo de 5 minutos. Al establecer un TTL mínimo de 15 minutos, el número de consultas necesarias se reduce al 29%. Un TTL mínimo de 1 hora lo hace caer al 17%. Esa es una diferencia significativa!
¿Qué tal no cambiar nada del lado del servidor, sino tener cachés de DNS de cliente (enrutadores, resolvers locales y cachés?) configurando un TTL mínimo en su lugar?
El número de consultas requeridas se reduce del 47% al 34% al establecer un TTL mínimo de 5 minutos, al 25% con un mínimo de 15 minutos y al 13% con un mínimo de 1 hora. 40 minutos tal vez un punto dulce. El impacto de ese cambio mínimo es enorme.
¿cuáles son las implicaciones?
Por supuesto, un servicio puede cambiar a un nuevo proveedor de nube, un nuevo servidor, una nueva red, lo que requiere que los clientes utilicen registros DNS actualizados. Y tener TTLs razonablemente bajos ayuda a que la transición no tenga fricción. Sin embargo, nadie que se mude a una nueva infraestructura esperará que los clientes usen los nuevos registros DNS en 1, 5 o 15 minutos.
Establecer un TTL mínimo de 40 minutos en lugar de 5 minutos no impedirá que los usuarios accedan al servicio. Sin embargo, reducirá drásticamente la latencia y mejorará la privacidad (más consultas = más oportunidades de seguimiento) y la confiabilidad al evitar consultas innecesarias.
Por supuesto, los RFC dicen que las TTL deben respetarse estrictamente. Pero la realidad es que el DNS se ha vuelto ineficiente.
Si está operando servidores DNS autoritativos, vuelva a visitar sus TTL. ¿De verdad necesitas que estos sean ridículamente bajos?
Leer: Cómo elegir valores TTL de DNS
Claro, hay razones válidas para usar TTL de DNS bajos. Pero no para que el 75% de Internet sirva contenido que en su mayoría es inmutable, pero que no tiene sentido almacenar en caché. Y si, por cualquier motivo, realmente necesita usar TTLs de DNS bajos, también asegúrese de que la caché tampoco funcione en su sitio web. Por las mismas razones.
Si utiliza una caché de DNS local, como dnscrypt-proxy, que permite establecer TTL mínimos, utilice esa función. Esto está bien. No pasará nada malo. Establezca ese TTL mínimo en algo entre 40 minutos (2400 segundos) y 1 hora; este es un rango perfectamente razonable.
Adaptado del post original que apareció en 00f.net