La baja latencia de DNS es clave para una navegación rápida en Internet. Para minimizarlo, es importante seleccionar cuidadosamente los servidores DNS y . Pero el primer paso es deshacerse de consultas inútiles.
Es por eso que DNS se diseñó originalmente como un protocolo con alta capacidad de almacenamiento en caché. Los administradores de zona establecen un tiempo de vida (TTL) para entradas individuales y los resolutores utilizan esta información cuando almacenan entradas en la memoria para evitar tráfico innecesario.
¿Es eficaz el almacenamiento en caché? Hace un par de años, mi pequeña investigación demostró que no era perfecto. Echemos un vistazo a la situación actual.
Para recopilar información, parcheé para guardar el valor TTL de la respuesta. Se define como el TTL mínimo de sus registros para cada solicitud entrante. Esto proporciona una buena visión general de la distribución TTL del tráfico real y también tiene en cuenta la popularidad de las solicitudes individuales. La versión parcheada del servidor funcionó durante varias horas.
El conjunto de datos resultante consta de 1 registros (nombre, qtype, TTL, marca de tiempo). Aquí está la distribución TTL general (el eje X es TTL en segundos):
Aparte de un pequeño aumento en 86 (principalmente para registros SOA), está bastante claro que los TTL están en el rango bajo. Miremos más de cerca:
De acuerdo, los TTL superiores a 1 hora no son estadísticamente significativos. Entonces centrémonos en el rango 0−3600:
La mayoría de los TTL son de 0 a 15 minutos:
La gran mayoría son de 0 a 5 minutos:
No es muy bueno.
La distribución acumulativa hace que el problema sea aún más obvio:
La mitad de las respuestas DNS tienen un TTL de 1 minuto o menos y tres cuartas partes tienen un TTL de 5 minutos o menos.
Pero espera, en realidad es peor. Después de todo, esto es TTL de servidores autorizados. Sin embargo, los solucionadores de clientes (por ejemplo, enrutadores, cachés locales) reciben un TTL de los solucionadores ascendentes y disminuye cada segundo.
Por lo tanto, el cliente puede utilizar cada entrada por, en promedio, la mitad del TTL original antes de enviar una nueva solicitud.
¿Quizás estos TTL tan bajos solo se aplican a solicitudes inusuales y no a sitios web y API populares? Echemos un vistazo:
El eje X es TTL, el eje Y es la popularidad de la consulta.
Desafortunadamente, las consultas más populares también son las peores para almacenar en caché.
Hagamos zoom:
Veredicto: es realmente malo. Ya era malo antes, pero empeoró aún más. El almacenamiento en caché de DNS se ha vuelto prácticamente inútil. A medida que menos personas utilizan el solucionador de DNS de su ISP (por buenas razones), el aumento de la latencia se vuelve más notorio.
El almacenamiento en caché de DNS se ha vuelto útil sólo para contenido que nadie visita.
Tenga en cuenta también que el software puede interpretar TTL bajos.
¿Por qué es eso?
¿Por qué los registros DNS están configurados con un TTL tan bajo?
- Los balanceadores de carga heredados se quedaron con la configuración predeterminada.
- Hay mitos de que el equilibrio de carga de DNS depende de TTL (esto no es cierto: desde los días de Netscape Navigator, los clientes han elegido una dirección IP aleatoria de un conjunto de RR y han probado de forma transparente otra si no pueden conectarse)
- Los administradores quieren aplicar los cambios inmediatamente, por lo que es más fácil planificar.
- El administrador de un servidor DNS o equilibrador de carga considera que su tarea es implementar de manera eficiente la configuración que los usuarios solicitan y no acelerar los sitios y servicios.
- Los TTL bajos le brindan tranquilidad.
- Inicialmente, las personas establecen TTL bajos para las pruebas y luego se olvidan de cambiarlos.
No incluí "conmutación por error" en la lista porque cada vez es menos relevante. Si necesita redirigir a los usuarios a otra red sólo para mostrar una página de error cuando todo lo demás está roto, probablemente sea aceptable un retraso de más de 1 minuto.
Además, un TTL de un minuto significa que si los servidores DNS autorizados se bloquean durante más de 1 minuto, nadie más podrá acceder a los servicios dependientes. Y la redundancia no ayudará si la causa es un error de configuración o un hack. Por otro lado, con TTL razonables, muchos clientes seguirán utilizando la configuración anterior y nunca notarán nada.
Los servicios CDN y los balanceadores de carga son en gran parte culpables de los TTL bajos, especialmente cuando combinan CNAME con TTL bajos y registros con TTL igualmente bajos (pero independientes):
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Siempre que caduque el CNAME o cualquiera de los registros A, se debe enviar una nueva solicitud. Ambos tienen un TTL de 30 segundos, pero no es lo mismo. El TTL promedio real será de 15 segundos.
¡Pero espera! Es aún peor. Algunos solucionadores se comportan muy mal en esta situación con dos TTL bajos asociados:
$ perforar raw.githubusercontent.com @ 4.2.2.2 raw.githubusercontent.com. 1 EN CNAME github.map.fastly.net. github.map.fastly.net. 1 EN UN 151.101.16.133
El solucionador de Level3 probablemente se ejecuta en BIND. Si continúa enviando esta solicitud, siempre se devolverá un TTL de 1. Básicamente, raw.githubusercontent.com nunca se almacena en caché.
Aquí hay otro ejemplo de una situación similar con un dominio muy popular:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.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.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Al menos tres registros CNAME. Sí. Uno tiene un TTL decente, pero es completamente inútil. Otros CNAME tienen un TTL inicial de 60 segundos, pero para dominios akamai.net el TTL máximo es de 20 segundos y ninguno de ellos está en fase.
¿Qué pasa con los dominios que sondean constantemente los dispositivos Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-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.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
El mismo problema que Firefox y TTL se atascará en 1 segundo la mayor parte del tiempo cuando se utilice el solucionador de nivel 3.
¿Dropbox?
$ taladro client.dropbox.com @ 8.8.8.8 client.dropbox.com. 7 EN CNAME client.dropbox-dns.com. cliente.dropbox-dns.com. 59 EN UN taladro de 162.125.67.3 $ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 EN CNAME client.dropbox-dns.com. cliente.dropbox-dns.com. 1 EN UN 162.125.64.3
en la grabacion safebrowsing.googleapis.com El valor TTL es de 60 segundos, como los dominios de Facebook. Y, de nuevo, desde el punto de vista del cliente, estos valores se reducen a la mitad.
¿Qué tal establecer un TTL mínimo?
Utilizando el nombre, el tipo de solicitud, el TTL y la marca de tiempo almacenada originalmente, escribí un script para simular 1,5 millones de solicitudes que pasaban por un solucionador de almacenamiento en caché para estimar el volumen de solicitudes innecesarias enviadas debido a una entrada de caché vencida.
El 47,4% de las solicitudes se realizaron después de que un expediente existente hubiera caducado. Esto es excesivamente alto.
¿Cuál será el impacto en el almacenamiento en caché si se establece el TTL mínimo?
El eje X son los valores mínimos de TTL. Los registros con TTL de origen superiores a este valor no se ven afectados.
El eje Y es el porcentaje de solicitudes de un cliente que ya tiene una entrada en caché, pero ha caducado y está realizando una nueva solicitud.
La proporción de solicitudes "extra" se reduce del 47 % al 36 % simplemente estableciendo el TTL mínimo en 5 minutos. Al establecer el TTL mínimo en 15 minutos, el número de estas solicitudes se reduce al 29%. Un TTL mínimo de 1 hora los reduce al 17%. ¡Diferencia significativa!
¿Qué tal no cambiar nada en el lado del servidor, sino establecer el TTL mínimo en las cachés de DNS del cliente (enrutadores, solucionadores locales)?
El número de solicitudes requeridas cae del 47% al 34% con 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. Quizás 40 minutos sea lo óptimo.
El impacto de este pequeño cambio es enorme.
¿Cuáles son las implicaciones?
Por supuesto, el servicio se puede trasladar a un nuevo proveedor de nube, un nuevo servidor, una nueva red, lo que requiere que los clientes utilicen los registros DNS más recientes. Y un TTL bastante pequeño ayuda a realizar esa transición de manera suave e imperceptible. Pero con la transición a una nueva infraestructura, nadie espera que los clientes migren a nuevos registros DNS en 1 minuto, 5 minutos o 15 minutos. Establecer el TTL mínimo en 40 minutos en lugar de 5 minutos no impedirá que los usuarios accedan al servicio.
Sin embargo, esto reducirá significativamente la latencia y mejorará la privacidad y confiabilidad al evitar solicitudes innecesarias.
Por supuesto, los RFC dicen que se debe seguir estrictamente el TTL. Pero la realidad es que el sistema DNS se ha vuelto demasiado ineficiente.
Si está trabajando con servidores DNS autorizados, verifique sus TTL. ¿Realmente necesitas valores tan ridículamente bajos?
Por supuesto, existen buenas razones para establecer TTL pequeños para los registros DNS. Pero no para el 75% del tráfico DNS que permanece prácticamente sin cambios.
Y si por alguna razón realmente necesita usar TTL bajos para DNS, al mismo tiempo asegúrese de que su sitio no tenga habilitado el almacenamiento en caché. Por las mismas razones.
Si tiene un caché DNS local en ejecución, como que le permite establecer TTL mínimos, utilice esta función. Esto esta bien. No pasará nada malo. Establezca el TTL mínimo en aproximadamente 40 minutos (2400 segundos) y 1 hora. Un rango bastante razonable.
Fuente: habr.com