A baixa latência de DNS é fundamental para uma navegação rápida na Internet. Para minimizá-lo, é importante selecionar cuidadosamente os servidores DNS e . Mas o primeiro passo é livrar-se de consultas inúteis.
É por isso que o DNS foi originalmente projetado como um protocolo altamente armazenável em cache. Os administradores de zona definem um tempo de vida (TTL) para entradas individuais, e os resolvedores usam essas informações ao armazenar entradas na memória para evitar tráfego desnecessário.
O cache é eficaz? Alguns anos atrás, minha pequena pesquisa mostrou que não era perfeito. Vamos dar uma olhada na situação atual.
Para coletar informações que eu corrigi para salvar o valor TTL da resposta. É definido como o TTL mínimo de seus registros para cada solicitação recebida. Isto dá uma boa visão geral da distribuição TTL do tráfego real e também leva em consideração a popularidade de solicitações individuais. A versão corrigida do servidor funcionou por várias horas.
O conjunto de dados resultante consiste em 1 registros (nome, qtype, TTL, carimbo de data/hora). Aqui está a distribuição geral do TTL (o eixo X é o TTL em segundos):
Além de um pequeno aumento em 86 (principalmente para registros SOA), está bastante claro que os TTLs estão na faixa baixa. Vamos olhar mais de perto:
Ok, TTLs superiores a 1 hora não são estatisticamente significativos. Então vamos nos concentrar no intervalo 0–3600:
A maioria dos TTLs vai de 0 a 15 minutos:
A grande maioria é de 0 a 5 minutos:
Não é muito bom.
A distribuição cumulativa torna o problema ainda mais óbvio:
Metade das respostas DNS tem um TTL de 1 minuto ou menos, e três quartos têm um TTL de 5 minutos ou menos.
Mas espere, na verdade é pior. Afinal, este é o TTL de servidores autorizados. No entanto, os resolvedores de clientes (por exemplo, roteadores, caches locais) recebem um TTL dos resolvedores upstream e diminui a cada segundo.
Assim, o cliente pode realmente usar cada entrada por, em média, metade do TTL original antes de enviar uma nova solicitação.
Talvez esses TTLs muito baixos se apliquem apenas a solicitações incomuns e não a sites e APIs populares? Vamos dar uma olhada:
O eixo X é TTL, o eixo Y é a popularidade da consulta.
Infelizmente, as consultas mais populares também são as piores para armazenar em cache.
Vamos ampliar:
Veredicto: é muito ruim. Já estava ruim antes, mas ficou ainda pior. O cache DNS tornou-se praticamente inútil. À medida que menos pessoas usam o resolvedor DNS do seu ISP (por boas razões), o aumento na latência se torna mais perceptível.
O cache DNS tornou-se útil apenas para conteúdo que ninguém visita.
Observe também que o software pode interpretar TTLs baixos.
Por que isso?
Por que os registros DNS estão configurados com um TTL tão baixo?
- Os balanceadores de carga legados ficaram com configurações padrão.
- Existem mitos de que o balanceamento de carga DNS depende do TTL (isso não é verdade - desde os dias do Netscape Navigator, os clientes escolhem um endereço IP aleatório de um conjunto de RRs e tentam outro de forma transparente se não conseguirem se conectar)
- Os administradores desejam aplicar as alterações imediatamente, por isso é mais fácil planejar.
- O administrador de um servidor DNS ou balanceador de carga vê sua tarefa como implantar com eficiência a configuração solicitada pelos usuários, e não acelerar sites e serviços.
- TTLs baixos proporcionam tranquilidade.
- As pessoas inicialmente definem TTLs baixos para testes e depois esquecem de alterá-los.
Não incluí "failover" na lista porque está se tornando cada vez menos relevante. Se você precisar redirecionar usuários para outra rede apenas para exibir uma página de erro quando absolutamente todo o resto estiver quebrado, um atraso de mais de 1 minuto provavelmente será aceitável.
Além disso, um TTL de um minuto significa que se os servidores DNS autoritativos forem bloqueados por mais de 1 minuto, ninguém mais poderá acessar os serviços dependentes. E a redundância não ajudará se a causa for um erro de configuração ou um hack. Por outro lado, com TTLs razoáveis, muitos clientes continuarão a usar a configuração anterior e nunca notarão nada.
Os serviços CDN e balanceadores de carga são os principais culpados pelos TTLs baixos, especialmente quando combinam CNAMEs com TTLs baixos e registros com TTLs igualmente baixos (mas 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 o CNAME ou algum dos registros A expirar, uma nova solicitação deverá ser enviada. Ambos têm um TTL de 30 segundos, mas não é a mesma coisa. O TTL médio real será de 15 segundos.
Mas espere! É ainda pior. Alguns resolvedores se comportam muito mal nesta situação com dois TTLs baixos associados:
$ perfurar raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 EM CNAME github.map.fastly.net. github.map.fastly.net. 1 EM UM 151.101.16.133
O resolvedor Level3 provavelmente roda em BIND. Se você continuar enviando esta solicitação, sempre será retornado um TTL de 1. Essencialmente, raw.githubusercontent.com nunca é armazenado em cache.
Aqui está outro exemplo de tal situação com um domínio muito 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
Pelo menos três registros CNAME. Sim. Um deles tem um TTL decente, mas é completamente inútil. Outros CNAMEs têm um TTL inicial de 60 segundos, mas para domínios akamai.net o TTL máximo é de 20 segundos e nenhum deles está em fase.
E quanto aos domínios que pesquisam 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 do Firefox e do TTL ficará travado em 1 segundo na maioria das vezes ao usar o resolvedor Level3.
Dropbox?
$ perfurar client.dropbox.com @8.8.8.8 client.dropbox.com. 7 EM CNAME client.dropbox-dns.com. cliente.dropbox-dns.com. 59 IN A 162.125.67.3 $ perfurar client.dropbox.com @4.2.2.2 client.dropbox.com. 1 EM CNAME client.dropbox-dns.com. cliente.dropbox-dns.com. 1 EM UM 162.125.64.3
Na gravação safebrowsing.googleapis.com O valor TTL é de 60 segundos, como os domínios do Facebook. E, novamente, do ponto de vista do cliente, esses valores caíram pela metade.
Que tal definir um TTL mínimo?
Usando o nome, o tipo de solicitação, o TTL e o carimbo de data/hora originalmente armazenado, escrevi um script para simular 1,5 milhão de solicitações passando por um resolvedor de cache para estimar o volume de solicitações extras enviadas devido a uma entrada de cache expirada.
47,4% das solicitações foram feitas após a expiração de um registro existente. Isto é excessivamente alto.
Qual será o impacto no cache se o TTL mínimo for definido?
O eixo X são os valores mínimos de TTL. Registros com TTLs de origem acima desse valor não são afetados.
O eixo Y é a porcentagem de solicitações de um cliente que já possui uma entrada em cache, mas ela expirou e está fazendo uma nova solicitação.
A parcela de solicitações “extras” é reduzida de 47% para 36% simplesmente definindo o TTL mínimo para 5 minutos. Ao definir o TTL mínimo para 15 minutos, o número dessas solicitações cai para 29%. Um TTL mínimo de 1 hora os reduz para 17%. Diferença significante!
Que tal não alterar nada no lado do servidor, mas sim definir o TTL mínimo nos caches DNS do cliente (roteadores, resolvedores locais)?
O número de solicitações necessárias cai de 47% para 34% com TTL mínimo de 5 minutos, para 25% com mínimo de 15 minutos e para 13% com mínimo de 1 hora. Talvez 40 minutos seja o ideal.
O impacto desta pequena mudança é enorme.
Quais são as consequências?
É claro que o serviço pode ser movido para um novo provedor de nuvem, um novo servidor, uma nova rede, exigindo que os clientes usem os registros DNS mais recentes. E um TTL bastante pequeno ajuda a fazer essa transição de maneira suave e imperceptível. Mas com a transição para a nova infraestrutura, ninguém espera que os clientes migrem para novos registros DNS dentro de 1 minuto, 5 minutos ou 15 minutos. Definir o TTL mínimo para 40 minutos em vez de 5 minutos não impedirá que os usuários acessem o serviço.
No entanto, isto reduzirá significativamente a latência e melhorará a privacidade e a fiabilidade, evitando pedidos desnecessários.
Claro, os RFCs dizem que o TTL deve ser rigorosamente seguido. Mas a realidade é que o sistema DNS tornou-se demasiado ineficiente.
Se você estiver trabalhando com servidores DNS autorizados, verifique seus TTLs. Você realmente precisa de valores tão ridiculamente baixos?
É claro que existem bons motivos para definir TTLs pequenos para registros DNS. Mas não para os 75% do tráfego DNS que permanecem praticamente inalterados.
E se por algum motivo você realmente precisar usar TTLs baixos para DNS, ao mesmo tempo certifique-se de que seu site não tenha o cache habilitado. Pelas mesmas razões.
Se você tiver um cache DNS local em execução, como que permite definir TTLs mínimos, use esta função. Isto é bom. Nada de ruim acontecerá. Defina o TTL mínimo para aproximadamente 40 minutos (2400 segundos) e 1 hora. Um intervalo bastante razoável.
Fonte: habr.com