A baixa latencia de DNS é fundamental para unha navegación rápida por Internet. Para minimizalo, é importante seleccionar coidadosamente os servidores DNS e . Pero o primeiro paso é desfacerse das consultas inútiles.
É por iso que o DNS foi orixinalmente deseñado como un protocolo altamente caché. Os administradores da zona establecen un tempo de vida (TTL) para as entradas individuais e os resolutores usan esta información cando almacenan entradas na memoria para evitar tráfico innecesario.
O caché é efectivo? Hai un par de anos, a miña pequena investigación demostrou que non era perfecto. Vexamos o estado actual das cousas.
Para recoller información que fixen para gardar o valor TTL para a resposta. Defínese como o TTL mínimo dos seus rexistros para cada solicitude entrante. Isto dá unha boa visión xeral da distribución TTL do tráfico real e tamén ten en conta a popularidade das solicitudes individuais. A versión parcheada do servidor funcionou durante varias horas.
O conxunto de datos resultante consta de 1 rexistros (nome, qtype, TTL, timestamp). Aquí está a distribución global de TTL (o eixe X é TTL en segundos):
Ademais dun pequeno aumento en 86 (principalmente para rexistros SOA), está bastante claro que os TTL están no rango baixo. Vexamos máis de cerca:
Está ben, os TTL superiores a 1 hora non son estatisticamente significativos. Entón centrámonos no intervalo 0−3600:
A maioría dos TTL son de 0 a 15 minutos:
A gran maioría son de 0 a 5 minutos:
Non é moi bo.
A distribución acumulada fai o problema aínda máis obvio:
A metade das respostas de DNS teñen un TTL de 1 minuto ou menos e tres cuartas partes teñen un TTL de 5 minutos ou menos.
Pero espera, en realidade é peor. Despois de todo, isto é TTL de servidores autorizados. Non obstante, os resolutores de clientes (por exemplo, enrutadores, cachés locais) reciben un TTL dos resolutores ascendentes e diminúe cada segundo.
Así, o cliente pode realmente usar cada entrada para, de media, a metade do TTL orixinal antes de enviar unha nova solicitude.
Quizais estes TTL tan baixos só se apliquen a solicitudes pouco habituais e non a sitios web e API populares? Imos botarlle unha ollada:
O eixe X é TTL, o eixe Y é a popularidade da consulta.
Desafortunadamente, as consultas máis populares tamén son as peores para almacenar na caché.
Imos ampliar:
Veredicto: é moi malo. Antes xa estaba mal, pero foi aínda peor. O almacenamento en caché de DNS volveuse practicamente inútil. A medida que menos persoas usan o resolvedor DNS do seu ISP (por boas razóns), o aumento da latencia faise máis notable.
O almacenamento en caché de DNS volveuse útil só para o contido que ninguén visita.
Teña en conta tamén que o software pode interpretar TTL baixos.
Por que isto?
Por que os rexistros DNS están configurados cun TTL tan baixo?
- Os equilibradores de carga heredados quedaron coa configuración predeterminada.
- Existen mitos de que o equilibrio de carga do DNS depende do TTL (isto non é certo: desde os tempos de Netscape Navigator, os clientes escolleron un enderezo IP aleatorio dun conxunto de RR e probaron outro de forma transparente se non poden conectarse)
- Os administradores queren aplicar os cambios inmediatamente, polo que é máis fácil planificar.
- O administrador dun servidor DNS ou equilibrador de carga considera que a súa tarefa é implementar de forma eficiente a configuración que solicitan os usuarios e non acelerar sitios e servizos.
- Os baixos TTL danche tranquilidade.
- A xente inicialmente establece TTL baixos para probar e despois esquécese de cambialos.
Non incluín "failover" na lista porque cada vez é menos relevante. Se precisa redirixir os usuarios a outra rede só para mostrar unha páxina de erro cando se rompe absolutamente todo o demais, probablemente se acepte un atraso superior a 1 minuto.
Ademais, un TTL dun minuto significa que se os servidores DNS autorizados se bloquean durante máis de 1 minuto, ninguén máis poderá acceder aos servizos dependentes. E a redundancia non axudará se a causa é un erro de configuración ou un hackeo. Por outra banda, con TTL razoables, moitos clientes seguirán usando a configuración anterior e nunca notarán nada.
Os servizos CDN e os equilibradores de carga son en gran parte os culpables dos baixos TTL, especialmente cando combinan CNAME con baixos TTL e rexistros con TTL igualmente baixos (pero independentes):
$ 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
Sempre que caduque o CNAME ou calquera dos rexistros A, debe enviarse unha nova solicitude. Ambos teñen un TTL de 30 segundos, pero non é o mesmo. O TTL medio real será de 15 segundos.
Pero agarda! Aínda é peor. Algúns resolvedores compórtanse moi mal nesta situación con dous TTL baixos 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 A 151.101.16.133
O resolvedor de nivel 3 probablemente se execute en BIND. Se continúas enviando esta solicitude, sempre se devolverá un TTL de 1. Esencialmente, raw.githubusercontent.com nunca se almacena en caché.
Aquí tes outro exemplo desta situación cun dominio moi 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
Polo menos tres rexistros CNAME. Ai. Un ten un TTL decente, pero é completamente inútil. Outros CNAME teñen un TTL inicial de 60 segundos, pero para dominios akamai.net o TTL máximo é de 20 segundos e ningún deles está en fase.
Que pasa cos dominios que sondean constantemente os 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
O mesmo problema que Firefox e TTL quedarán atascados en 1 segundo a maior parte do tempo ao usar o resolvedor de nivel 3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 EN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 NUN 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
Na gravación safebrowsing.googleapis.com O valor TTL é de 60 segundos, como os dominios de Facebook. E, de novo, desde o punto de vista do cliente, estes valores redúcense á metade.
Que tal establecer un TTL mínimo?
Usando o nome, o tipo de solicitude, o TTL e a marca de tempo almacenada orixinalmente, escribín un script para simular 1,5 millóns de solicitudes que pasan por un resolvedor de caché para estimar o volume de solicitudes innecesarias enviadas debido a unha entrada de caché caducada.
O 47,4% das solicitudes realizáronse despois de caducar un rexistro existente. Isto é razoablemente alto.
Cal será o impacto na memoria caché se se establece o TTL mínimo?
O eixe X son os valores mínimos de TTL. Os rexistros con TTL de orixe por riba deste valor non se ven afectados.
O eixe Y é a porcentaxe de solicitudes dun cliente que xa ten unha entrada na memoria caché, pero que caducou e está a realizar unha nova solicitude.
A porcentaxe de solicitudes "extra" redúcese do 47% ao 36% simplemente establecendo o TTL mínimo en 5 minutos. Ao establecer o TTL mínimo en 15 minutos, o número destas solicitudes cae ata o 29 %. Un TTL mínimo de 1 hora redúceos ao 17%. Diferenza significativa!
Que tal non cambiar nada no lado do servidor, senón establecer o TTL mínimo nos cachés DNS do cliente (routers, resolutores locais)?
O número de solicitudes necesarias cae do 47% ao 34% cun mínimo de 5 minutos de duración, ao 25% cun mínimo de 15 minutos e ao 13% cun mínimo de 1 hora. Quizais 40 minutos sexa o ideal.
O impacto deste pequeno cambio é enorme.
Cales son as consecuencias?
Por suposto, o servizo pódese mover a un novo provedor de nube, un novo servidor, unha nova rede, requirindo que os clientes utilicen os últimos rexistros DNS. E un TTL bastante pequeno axuda a facer esa transición de forma suave e imperceptible. Pero coa transición a unha nova infraestrutura, ninguén espera que os clientes migren a novos rexistros DNS en 1 minuto, 5 minutos ou 15 minutos. Establecer o TTL mínimo en 40 minutos en lugar de 5 minutos non impedirá que os usuarios accedan ao servizo.
Non obstante, isto reducirá significativamente a latencia e mellorará a privacidade e a fiabilidade ao evitar solicitudes innecesarias.
Por suposto, os RFC din que o TTL debe seguirse estrictamente. Pero a realidade é que o sistema DNS volveuse demasiado ineficiente.
Se está a traballar con servidores DNS autorizados, comprobe os seus TTL. Realmente necesitas valores tan ridículamente baixos?
Por suposto, hai boas razóns para establecer pequenos TTL para rexistros DNS. Pero non para o 75% do tráfico DNS que permanece practicamente sen cambios.
E se por algún motivo realmente necesitas usar TTL baixos para o DNS, asegúrate ao mesmo tempo de que o teu sitio non teña a caché activada. Polas mesmas razóns.
Se tes unha caché DNS local en execución, como que lle permite establecer TTL mínimos, use esta función. Isto está ben. Non pasará nada malo. Establece o TTL mínimo en aproximadamente 40 minutos (2400 segundos) e 1 hora. Un rango bastante razoable.
Fonte: www.habr.com