A baixa latência DNS é um fator crucial para um desempenho rápido na internet. Para minimizá-la, é importante escolher cuidadosamente os servidores DNS e . Mas, antes de tudo, é necessário eliminar as consultas inúteis.
É por isso que o DNS foi inicialmente criado como um protocolo altamente cacheável. Os administradores de zona definem o tempo de vida (TTL) para registros individuais, e os resolvedores usam essas informações ao armazenar registros na memória, para evitar tráfego desnecessário.
O cache está funcionando de forma eficaz? Há alguns anos, uma pequena pesquisa que fiz mostrou que não é perfeito. Vamos dar uma olhada na situação atual.
Para coletar informações, eu patchuei para manter o valor TTL para a resposta. Ele é definido como o menor TTL de seus registros, para cada consulta que chega. Isso fornece uma boa visão da distribuição de TTL do tráfego real, além de considerar a popularidade de consultas individuais. A versão patchada do servidor funcionou por algumas horas.
O conjunto de dados resultante consiste em 1.583.579 registros (nome, qtype, TTL, timestamp). Aqui está a distribuição geral do TTL (eixo X — é TTL em segundos):
Exceto por um leve pico em 86.400 (principalmente para registros SOA), é bem evidente que os TTL estão em uma faixa baixa. Vamos olhar mais de perto:
Bem, TTL acima de 1 hora são estatisticamente irrelevantes. Então, vamos nos concentrar na faixa de 0 a 3600:
A maioria dos TTL está entre 0 e 15 minutos:
A grande maioria está entre 0 e 5 minutos:
Isso não é muito bom.
A distribuição acumulada torna o problema ainda mais evidente:
Em metade das respostas DNS, o TTL é de 1 minuto ou menos, e em três quartos, é de 5 minutos ou menos.
Mas espere, na verdade está ainda pior. Esses são TTL de servidores autoritativos. No entanto, os resolvedores de clientes (como roteadores, caches locais) recebem TTL dos resolvedores ascendentes, e ele diminui a cada segundo.
Assim, o cliente pode usar cada registro, em média, por metade do TTL original, após o que enviará uma nova consulta.
Talvez esses TTL muito baixos se refiram apenas a consultas incomuns, e não a sites populares e APIs? Vamos dar uma olhada:
O eixo X é o TTL, o eixo Y é a popularidade das consultas.
Infelizmente, as consultas mais populares também são as que são cacheadas de forma menos eficiente.
Vamos aproximar:
Veredicto: tudo realmente está ruim. Já estava ruim antes, e agora ficou ainda pior. O cache de DNS se tornou praticamente inútil. À medida que cada vez menos pessoas usam o resolvedor DNS de seu provedor (por razões válidas), o aumento da latência se torna mais perceptível.
O cache de DNS só se tornou útil para conteúdos que ninguém visita.
Além disso, observe que o software pode os TTL baixos.
Por que isso acontece?
Por que os registros DNS têm um TTL tão baixo?
- Balanceadores de carga desatualizados permaneceram com as configurações padrão.
- Existem mitos de que o balanceamento de carga por DNS depende do TTL (isso não é verdade — desde os tempos do Netscape Navigator, os clientes selecionam um endereço IP aleatório de um conjunto de RR e tentam outro se não conseguem se conectar)
- Os administradores querem aplicar as alterações imediatamente porque isso facilita o planejamento.
- O administrador do servidor DNS ou do balanceador de carga vê como sua tarefa implantar de forma eficaz a configuração que os usuários solicitam, e não acelerar o funcionamento de sites e serviços.
- TTLs baixos trazem tranquilidade.
- As pessoas inicialmente configuram TTL baixos para testes e depois esquecem de alterá-los.
Não incluí a 'execução de falhas' na lista, pois isso está se tornando cada vez menos relevante. Se for necessário redirecionar usuários para outra rede apenas para exibir uma página de erro quando absolutamente tudo mais está quebrado, talvez uma latência de mais de 1 minuto seja aceitável.
Além disso, um TTL de um minuto significa que, se os servidores DNS autoritativos ficarem fora do ar por mais de um minuto, ninguém mais poderá acessar os serviços dependentes. E a redundância não ajudará se o problema for um erro de configuração ou um ataque. Por outro lado, com TTL razoáveis, muitos clientes continuarão a usar a configuração anterior e nunca notarão nada.
Os TTL baixos são em grande parte culpa dos serviços de CDN e dos balanceadores de carga, especialmente quando combinam CNAME com TTL baixos e registros com os mesmos TTL 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 um CNAME ou qualquer um dos registros A expira, é necessário enviar uma nova solicitação. Ambos têm um TTL de 30 segundos, mas não coincidem. O TTL médio real será de 15 segundos.
Mas espere! A situação é ainda pior. Alguns resolvedores se comportam muito mal em tal situação com dois TTL baixos 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
O resolvedor Level3 provavelmente está rodando em BIND. Se você continuar enviando essa solicitação, sempre retornará um TTL igual a 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. Ai. Um deles tem um TTL decente, mas isso é completamente inútil. Nos outros CNAME, o TTL inicial é de 60 segundos, mas para os domínios akamai.net o TTL máximo é de 20 segundos, e nenhum deles está em fase.
E quanto aos domínios que consultam constantemente 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 o Firefox, e o TTL na maior parte do tempo ficará preso em 1 segundo ao usar o resolvedor 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
No registro safebrowsing.googleapis.com o valor do TTL é de 60 segundos, assim como os domínios do Facebook. E, mais uma vez, do ponto de vista do cliente, esses valores são reduzidos pela metade.
E quanto à configuração de um TTL mínimo?
Usando o nome, tipo de solicitação, TTL e o carimbo de data/hora inicialmente salvo, escrevi um script para simular 1,5 milhão de solicitações passando por um resolvedor de cache, para avaliar a quantidade de solicitações adicionais enviadas devido ao registro de cache expirado.
47,4% das solicitações foram feitas após a expiração do registro existente. Isso é excessivamente alto.
Qual será o impacto no caching se um TTL mínimo for definido?
O eixo X representa os valores mínimos de TTL. Registros com TTL original superior a este valor não são afetados.
O eixo Y representa a porcentagem de consultas do cliente que já possui um registro em cache, mas cuja validade expirou, fazendo uma nova solicitação.
A proporção de consultas 'desnecessárias' diminui de 47% para 36% simplesmente configurando o TTL mínimo para 5 minutos. Ao configurar o TTL mínimo para 15 minutos, essa quantidade cai para 29%. Um TTL mínimo de 1 hora reduz isso para 17%. Uma diferença significativa!
Que tal não fazer nenhuma alteração no lado do servidor e, em vez disso, estabelecer TTL mínimos nos caches DNS dos clientes (roteadores, resolvedores locais)?
O número de consultas necessárias diminui de 47% para 34% ao definir um TTL mínimo de 5 minutos, para 25% com um mínimo de 15 minutos e para 13% com um mínimo de 1 hora. Talvez o valor ideal seja de 40 minutos.
O impacto dessa mudança mínima é enorme.
Quais são as consequências?
Claro, o serviço pode ser migrado para um novo provedor de nuvem, um novo servidor, uma nova rede, exigindo que os clientes utilizem os registros DNS mais recentes. Um TTL baixo ajuda a realizar essa transição de forma suave e discreta. Mas, ao migrar para uma nova infraestrutura, ninguém espera que os clientes mudem para novos registros DNS em 1 minuto, 5 minutos ou 15 minutos. Configurar um tempo de vida mínimo de 40 minutos em vez de 5 minutos não impede que os usuários acessem o serviço.
No entanto, isso permitirá uma redução significativa na latência e aumentará a privacidade e a confiabilidade, evitando consultas desnecessárias.
Claro, o RFC diz que devemos seguir rigorosamente o TTL. Mas a realidade é que o sistema DNS se tornou muito ineficiente.
Se você está trabalhando com servidores DNS autoritativos, por favor, verifique seus TTLs. Você realmente precisa de valores tão ridiculamente baixos?
Claro, existem boas razões para estabelecer TLs baixos para registros DNS. Mas não para 75% do tráfego DNS, que praticamente não muda.
E se por algum motivo você realmente precisar usar TLs baixos para DNS, certifique-se de que o cache do seu site não esteja ativado. Pelas mesmas razões.
Se você possui um cache DNS local em funcionamento, como , que permite definir TTL mínimos, utilize essa função. Está tudo bem. Nada de ruim acontecerá. Defina um TTL mínimo entre 40 minutos (2400 segundos) e 1 hora. É uma faixa perfeitamente razoável.
Fonte: habr.com
