Una baja latencia de DNS es un factor clave para un buen rendimiento en internet. Para minimizarla, es importante elegir cuidadosamente los servidores DNS y . Pero lo primero es deshacerse de las consultas innecesarias.
Por eso, el DNS fue diseñado originalmente como un protocolo altamente cacheable. Los administradores de zonas establecen el tiempo de vida (TTL) para cada registro, y los resolutores utilizan esta información al almacenar registros en memoria para evitar tráfico innecesario.
¿Es eficaz el caché? Hace un par de años, mi pequeña investigación mostró que no era perfecto. Veamos la situación actual.
Para recopilar información, modifiqué para conservar el valor TTL de la respuesta. Se define como el mínimo TTL de sus registros, para cada consulta entrante. Esto proporciona una buena visión de la distribución del TTL en el tráfico real, y también considera la popularidad de las consultas individuales. La versión modificada del servidor funcionó durante varias horas.
El conjunto de datos resultante consiste en 1,583,579 registros (nombre, qtype, TTL, timestamp). Aquí está la distribución general de TTL (el eje X es TTL en segundos):
Salvo por una pequeña cima en 86,400 (principalmente para registros SOA), es bastante obvio que los TTL están en un rango bajo. Miremos más de cerca:
Bien, los TTL de más de 1 hora no son estadísticamente significativos. Entonces, centrémonos en el rango de 0-3600:
La mayoría de los TTL están entre 0 y 15 minutos:
La abrumadora mayoría está entre 0 y 5 minutos:
Esto no es muy bueno.
La distribución acumulativa hace que el problema sea aún más evidente:
En la mitad de las respuestas DNS, el TTL es de 1 minuto o menos, y en tres cuartos, de 5 minutos o menos.
Pero espera, en realidad es aún peor. Este es el TTL de los servidores autoritativos. Sin embargo, los resolutores de clientes (como routers, cachés locales) obtienen el TTL de los resolutores ascendentes, y este disminuye cada segundo.
Así, el cliente puede usar en promedio cada registro durante la mitad del TTL original, después de lo cual enviará una nueva consulta.
¿Quizás estos TTL tan bajos solo se refieren a consultas inusuales, y no a sitios web populares y API? Veamos:
El eje X es TTL, el eje Y es la popularidad de las consultas.
Desafortunadamente, las consultas más populares son también las que peor se cachean.
Aproximemos:
Veredicto: todo está realmente mal. Ya había sido malo antes, y ahora es aún peor. La caché DNS se ha vuelto prácticamente inútil. A medida que cada vez menos personas utilizan el resolutor DNS de su proveedor (por razones válidas), el aumento de la latencia se vuelve más evidente.
La caché DNS solo se ha vuelto útil para contenido que nadie visita.
También tenga en cuenta que el software puede maneras los TTL bajos.
¿Por qué es así?
¿Por qué se establece un TTL tan bajo para los registros DNS?
- Los equilibradores de carga obsoletos han permanecido con la configuración por defecto.
- Existen mitos de que la equilibración de carga por DNS depende del TTL (esto no es cierto: desde los tiempos de Netscape Navigator, los clientes eligen un IP aleatorio de un conjunto de RR y prueban transparentemente otro si no pueden conectarse).
- Los administradores quieren aplicar los cambios de inmediato, por lo que es más fácil planificar.
- El administrador del servidor DNS o del equilibrador de carga ve su tarea como desplegar efectivamente la configuración que los usuarios solicitan, en lugar de acelerar los sitios y servicios.
- Los TTL bajos ofrecen tranquilidad.
- Las personas originalmente establecen TTL bajos para pruebas y luego se olvidan de cambiarlos.
No incluí en la lista la 'gestión de fallos', ya que esto es cada vez menos relevante. Si es necesario redirigir a los usuarios a otra red solo para mostrar una página de error cuando absolutamente todo lo demás ha fallado, probablemente una latencia de más de 1 minuto sea aceptable.
Además, un TTL de un minuto significa que si los servidores DNS autoritativos están bloqueados por más de un 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 hackeo. Por otro lado, con TTL razonables muchos clientes continuarán utilizando la configuración anterior y nunca notarán nada.
Los TTL bajos son en gran medida culpa de los servicios CDN y los equilibradores de carga, 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
Cada vez que expira un CNAME o cualquiera de los registros A, se debe enviar una nueva consulta. Ambos tienen un TTL de 30 segundos, pero no coinciden. El TTL medio real será de 15 segundos.
¡Pero espera! La situación es aún peor. Algunos resolutores se comportan muy mal en esta situación con dos TTL bajos relacionados:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
El resolutor Level3 probablemente funciona con BIND. Si sigues enviando esta consulta, siempre regresará un TTL igual a 1. En esencia, raw.githubusercontent.com nunca se almacena en caché.
Aquí hay otro ejemplo de una situación así 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. Ay. Uno tiene un TTL decente, pero esto es completamente inútil. En otros CNAME, el TTL inicial es de 60 segundos, pero para los dominios akamai.net el TTL máximo es de 20 segundos, y ninguno está en fase.
¿Qué pasa con los dominios que consultan continuamente a 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 en Firefox, y el TTL se quedará en 1 segundo la mayor parte del tiempo al utilizar el resolutor Level3.
¿Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.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.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
En el registro safebrowsing.googleapis.com el valor TTL es de 60 segundos, al igual que los dominios de Facebook. Y, nuevamente, desde el punto de vista del cliente, estos valores se reducen a la mitad.
¿Qué tal establecer un TTL mínimo?
Utilizando el nombre, tipo de consulta, TTL y la marca de tiempo inicialmente almacenada, escribí un script para simular 1.5 millones de consultas pasando por un resolutor de caché, para estimar la cantidad de consultas innecesarias enviadas debido a un registro de caché caducado.
El 47.4% de las consultas se realizaron después de la expiración del registro existente. Esto es inusualmente alto.
¿Cuál será el impacto en la caché si se establece un TTL mínimo?
El eje X son los valores mínimos de TTL. Los registros con TTL originales por encima de este valor no se ven afectados.
El eje Y es el porcentaje de solicitudes del cliente que ya tiene un registro en caché, pero su tiempo de vida ha expirado y hace una nueva solicitud.
La proporción de solicitudes "excesivas" disminuye del 47% al 36% al establecer un TTL mínimo de 5 minutos. Con un TTL mínimo de 15 minutos, esta cantidad se reduce al 29%. Un TTL mínimo de 1 hora la reduce al 17%. ¡Una diferencia significativa!
¿Qué tal si no cambiamos nada en el servidor, y en su lugar, establecemos los TTL mínimos en las cachés DNS de los clientes (enrutadores, resolutores locales)?
La cantidad de solicitudes necesarias disminuye 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. Posiblemente, el valor óptimo sea de 40 minutos.
El impacto de este pequeño cambio es enorme.
¿Cuáles son las consecuencias?
Por supuesto, se puede migrar el servicio a un nuevo proveedor de nube, nuevo servidor, nueva red, exigiendo a los clientes que utilicen los últimos registros DNS. Y un TTL suficientemente bajo ayuda a realizar esta transición de manera suave y discreta. Pero con la migración a nueva infraestructura, nadie espera que los clientes cambien a los nuevos registros DNS en un minuto, cinco minutos o quince minutos. Establecer una vida mínima de 40 minutos en lugar de 5 no impedirá que los usuarios accedan al servicio.
Sin embargo, esto permitirá reducir significativamente la latencia y mejorar la confidencialidad y confiabilidad, evitando solicitudes innecesarias.
Por supuesto, los RFC indican que se debe cumplir estrictamente con el TTL. Pero la realidad es que el sistema DNS se ha vuelto demasiado ineficiente.
Si trabaja con servidores DNS autoritativos, por favor, compruebe sus TTL. ¿Realmente necesita esos valores absurdamente bajos?
Por supuesto, hay buenas razones para establecer TTL bajos para los registros DNS. Pero no para el 75% del tráfico DNS que prácticamente no cambia.
Y si por alguna razón realmente necesita utilizar TTL bajos para DNS, asegúrese de que su sitio no tenga habilitada la caché. Por las mismas razones.
Si tiene un caché DNS local en funcionamiento, como , que permite configurar un TTL mínimo, utiliza esta función. Está bien. No pasará nada malo. Establece un TTL mínimo de entre 40 minutos (2400 segundos) y 1 hora. Un rango bastante razonable.
Fuente: habr.com
