La baja latencia de DNS es un factor clave para la navegación rápida por Internet. Para minimizarlo, es importante seleccionar cuidadosamente los servidores DNS y la retransmisión anónima . Pero lo primero que debe hacer es deshacerse de las consultas inútiles.

Es por eso que DNS se creó originalmente como un protocolo altamente almacenado en caché. Los administradores de zona establecen una vida útil (TTL) para registros individuales, y los resolutores usan esta información cuando almacenan registros en la memoria para evitar tráfico innecesario.

¿Es eficiente el almacenamiento en caché? Hace un par de años, mi pequeña investigación demostró que no era perfecta. Echa un vistazo a la situación actual.

Para recopilar información, parcheé el servidor DNS cifrado para almacenar el valor TTL para la respuesta. Se define como el TTL mínimo de sus entradas para cada solicitud entrante. Esto ofrece una buena visión general de la distribución del tráfico real TTL 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.583.579 registros (nombre, qtype, TTL, marca de tiempo). Aquí está la distribución general de TTL (el eje X es TTL en segundos):



Además del montículo menor en 86,400 (principalmente para registros SOA), es bastante obvio que los TTL están en el rango bajo. Echemos un vistazo más de cerca:



Bueno, los TTL de más de 1 hora no son estadísticamente significativos. Luego concéntrese en el rango 0−3600:



La mayoría de TTL de 0 a 15 minutos:



La gran mayoría de 0 a 5 minutos:



Esto no es muy bueno.

La distribución acumulativa hace que el problema sea aún más obvio:



En la mitad de las respuestas de DNS, TTL es de 1 minuto o menos, y en tres cuartos de 5 minutos o menos.

Pero espera, en realidad es peor. Después de todo, esto es TTL de servidores autorizados. Sin embargo, los resolvers de clientes (por ejemplo, enrutadores, cachés locales) reciben TTL de resolvers superiores y disminuye cada segundo.

Por lo tanto, el cliente puede usar cada registro, en promedio, para la mitad del TTL original, después de lo cual enviará una nueva solicitud.

¿Quizás estos TTL muy bajos se refieren solo a solicitudes inusuales, no a sitios web y API populares? A ver:



El eje X es TTL, el eje Y es popularidad de consulta.

Lamentablemente, las consultas más populares también se almacenan en caché lo peor de todo.

Acercar:



Veredicto: todo es realmente malo. Antes era malo, pero empeoró. El almacenamiento en caché de DNS se ha vuelto prácticamente inútil. A medida que menos personas usan el solucionador DNS de su ISP (por una buena razón), el aumento de la latencia se hace más notable.

El almacenamiento en caché de DNS se ha vuelto útil solo para contenido que nadie visita.

También tenga en cuenta que el software puede interpretar TTL bajos de manera diferente .

¿Por qué?

¿Por qué se establece un TTL tan pequeño para los registros DNS?

• Los equilibradores de carga obsoletos se quedan con la configuración predeterminada.
  
• Hay mitos de que el equilibrio de carga de DNS depende de TTL (esto no es así; desde los días de Netscape Navigator, los clientes eligen una dirección IP aleatoria del conjunto de RR y prueban otra de forma transparente si no pueden conectarse)
  
• Los administradores desean aplicar los cambios de inmediato, porque es más fácil de planificar.
  
• El administrador del servidor DNS o el equilibrador de carga considera que su tarea es implementar de manera efectiva la configuración que solicitan los usuarios, en lugar de acelerar los sitios y servicios.
  
• TTL bajo da tranquilidad.
  
• Inicialmente, las personas establecen TTL bajos para las pruebas y luego se olvidan de cambiarlos.

No incluí "failover" en la lista, ya que todo esto es menos relevante. Si necesita redirigir a los usuarios a otra red solo para mostrar la página de error, cuando absolutamente todo lo demás se haya roto, probablemente sea aceptable un retraso de más de 1 minuto.

Además, el minuto TTL significa que si los servidores DNS autorizados están bloqueados por más de 1 minuto, nadie más puede acceder a los servicios dependientes. Y la redundancia no ayudará si la causa es un error de configuración o pirateo. Por otro lado, con TTL razonables, muchos clientes continuarán utilizando la configuración anterior y nunca notarán nada.

Para TTL bajos, los servicios CDN y los equilibradores de carga son en gran parte los culpables, especialmente cuando combinan CNAME con TTL pequeños y registros con TTL igualmente pequeños (pero independientes):

  $ drill raw.githubusercontent.com
 raw.githubusercontent.com.  9 EN CNAME github.map.fastly.net.
 github.map.fastly.net.  20 EN UN 151.101.128.133
 github.map.fastly.net.  20 EN UN 151.101.192.133
 github.map.fastly.net.  20 EN UN 151.101.0.133
 github.map.fastly.net.  20 EN UN 151.101.64.133 

Siempre que caduque un CNAME o cualquiera de los registros A, debe enviar una nueva solicitud. Ambos tienen un TTL de 30 segundos, pero no coincide. El promedio real de TTL será de 15 segundos.

Pero espera! Aún peor Algunos solucionadores se comportan muy mal en esta situación con dos TTL bajos asociados:

  $ drill raw.githubusercontent.com @ 4.2.2.2
 raw.githubusercontent.com.  1 EN CNAME github.map.fastly.net.
 github.map.fastly.net.  1 EN A 151.101.16.133 

El solucionador Level3 probablemente funciona en BIND. Si sigue enviando esta solicitud, siempre se devolverá un TTL de 1. Esencialmente, raw.githubusercontent.com nunca se almacena en caché.

Aquí hay otro ejemplo de tal situación con un dominio muy popular:

  $ drill detectportal.firefox.com @ 1.1.1.1
 detectportal.firefox.com.  25 EN CNAME detectportal.prod.mozaws.net.
 detectportal.prod.mozaws.net.  26 EN CNAME detectportal.firefox.com-v2.edgesuite.net.
 detectportal.firefox.com-v2.edgesuite.net.  10668 EN CNAME a1089.dscd.akamai.net.
 a1089.dscd.akamai.net.  10 EN UN 104.123.50.106
 a1089.dscd.akamai.net.  10 EN UN 104.123.50.88 

Al menos tres registros CNAME. Aw Uno tiene un TTL decente, pero es completamente inútil. En otros CNAME, el TTL inicial es de 60 segundos, pero para los dominios akamai.net TTL máximo es de 20 segundos, y ninguno de ellos está en fase.

¿Qué pasa con los dominios que sondean constantemente los dispositivos de Apple?

  $ drill 1-courier.push.apple.com @ 4.2.2.2
 1-courier.push.apple.com.  1253 EN CNAME 1.courier-push-apple.com.akadns.net.
 1.courier-push-apple.com.akadns.net.  1 EN CNAME gb-courier-4.push-apple.com.akadns.net.
 gb-courier-4.push-apple.com.akadns.net.  1 EN UN 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net.  1 EN UN 17.57.146.85 

El mismo problema que tiene Firefox, y TTL se atascará durante 1 segundo la mayor parte del tiempo cuando use el solucionador Level3.

Dropbox?

  $ drill client.dropbox.com @ 8.8.8.8
 client.dropbox.com.  7 EN CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  59 EN UN 162.125.67.3

 $ drill client.dropbox.com @ 4.2.2.2
 client.dropbox.com.  1 EN CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  1 EN A 162.125.64.3 

safebrowsing.googleapis.com un TTL de 60 segundos, al igual que con 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, el tipo de solicitud, TTL y la marca de tiempo originalmente guardada, escribí un script para simular 1.5 millones de solicitudes que pasan a través de un resolutor de almacenamiento en caché para estimar la cantidad de solicitudes adicionales enviadas debido a una entrada de caché caducada.

El 47,4% de las solicitudes se realizaron después de la expiración del registro existente. Esto es irracionalmente alto.

¿Cuál será el efecto sobre el almacenamiento en caché si se establece el TTL mínimo?



El eje X es el valor mínimo de TTL. Los registros con TTL de origen por encima de este valor no se ven afectados.

Eje Y: porcentaje de solicitudes de un cliente que ya tiene un registro en caché, pero ha caducado y realiza una nueva solicitud.

El porcentaje de solicitudes "adicionales" se reduce del 47% al 36% simplemente configurando 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%. La gran diferencia!

¿Qué tal no cambiar nada en el lado del servidor, sino establecer el TTL mínimo en cachés DNS del cliente (enrutadores, solucionadores locales)?



El número de solicitudes requeridas se reduce del 47% al 34% al establecer el TTL mínimo en 5 minutos, al 25% con un mínimo de 15 minutos y hasta el 13% con un mínimo de 1 hora. Quizás el valor óptimo es de 40 minutos.

El impacto de este cambio mínimo es enorme.

¿Cuáles son las implicaciones?

Por supuesto, el servicio se puede transferir a un nuevo proveedor de la nube, un nuevo servidor, una nueva red, lo que requiere que los clientes utilicen los últimos registros DNS. Y un TTL suficientemente pequeño ayuda a hacer esa transición sin problemas y sin problemas. Pero con la transición a una nueva infraestructura, nadie espera que los clientes cambien a nuevos registros DNS en 1 minuto, 5 minutos o 15 minutos. Establecer una vida mínima de 40 minutos en lugar de 5 minutos no impedirá que los usuarios accedan al servicio.

Sin embargo, esto reducirá significativamente la latencia y aumentará la confidencialidad y confiabilidad, evitando solicitudes innecesarias.

Por supuesto, los RFC dicen que necesita hacer cumplir estrictamente el TTL. Pero la realidad es que el sistema DNS se ha vuelto demasiado ineficiente.

Si trabaja con servidores DNS autorizados, verifique su TTL. ¿Realmente necesitas valores tan ridículamente bajos?

Por supuesto, hay buenas razones para configurar TTL pequeños para registros DNS. Pero no para el 75% del tráfico de DNS, que permanece prácticamente sin cambios.

Y si por alguna razón realmente necesita usar TTL bajo para DNS, al mismo tiempo asegúrese de que el almacenamiento en caché no esté habilitado en su sitio. Por las mismas razones.

Si tiene un caché de DNS local, como dnscrypt-proxy , que le permite establecer el TTL mínimo, use esta función. Esto es normal Nada malo sucederá. Establezca el TTL mínimo entre aproximadamente 40 minutos (2400 segundos) y 1 hora. Un rango bastante razonable.