A baixa latência do DNS é um fator essencial para uma navegação rápida na Internet. Para minimizá-lo, é importante selecionar cuidadosamente servidores DNS e retransmissão anônima . Mas a primeira coisa a fazer é se livrar de consultas inúteis.

É por isso que o DNS foi criado originalmente como um protocolo altamente armazenado em cache. Os administradores de zona definem uma vida útil (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 é eficiente? Há alguns anos, minha pequena pesquisa mostrou que não era perfeita. Dê uma olhada no estado atual das coisas.

Para coletar informações, corrigi o servidor DNS criptografado para armazenar o valor TTL da resposta. É definido como o TTL mínimo de suas entradas para cada solicitação recebida. Isso fornece uma boa visão geral da distribuição do tráfego real TTL 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.583.579 registros (nome, qtype, TTL, registro de data e hora). Aqui está a distribuição geral do TTL (o eixo X é TTL em segundos):



Além do pequeno monte em 86.400 (principalmente para registros SOA), é bastante óbvio que os TTLs estão na faixa baixa. Vamos dar uma olhada:



Bem, TTLs ao longo de 1 hora não são estatisticamente significativos. Em seguida, foque no intervalo de 0 a 3600:



A maioria TTL de 0 a 15 minutos:



A grande maioria de 0 a 5 minutos:



Isso não é muito bom.

A distribuição cumulativa torna o problema ainda mais óbvio:



Na metade das respostas do DNS, o TTL é de 1 minuto ou menos e, em três quartos, de 5 minutos ou menos.

Mas espere, é realmente pior. Afinal, isso é TTL de servidores autorizados. No entanto, os resolvedores de clientes (por exemplo, roteadores, caches locais) recebem TTLs de resolvedores mais altos e diminuem a cada segundo.

Assim, o cliente pode realmente usar cada registro, em média, pela metade do TTL original, após o qual enviará uma nova solicitação.

Talvez esses TTLs muito baixos digam respeito apenas a solicitações incomuns, não a sites e APIs populares? Vamos ver:



O eixo X é TTL, o eixo Y é a popularidade da consulta.

Infelizmente, as consultas mais populares também são armazenadas em cache, o pior de tudo.

Mais zoom:



Veredicto: tudo está muito ruim. Era ruim antes, mas piorou. O cache do 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 está se tornando mais perceptível.

O cache do DNS tornou-se útil apenas para o conteúdo que ninguém visita.

Observe também que o software pode interpretar TTLs baixos de maneira diferente .

Por que isso?

Por que um TTL tão pequeno é definido para registros DNS?

• Os balanceadores de carga desatualizados são deixados com as configurações padrão.
  
• Há mitos de que o balanceamento de carga do DNS depende do TTL (não é assim - desde o Netscape Navigator, os clientes escolhem um endereço IP aleatório do conjunto RR e tentam outro de forma transparente se não conseguirem se conectar)
  
• Os administradores desejam aplicar as alterações imediatamente, porque é mais fácil planejar.
  
• O administrador do servidor DNS ou do balanceador de carga vê sua tarefa como efetivamente implantar a configuração solicitada pelos usuários, em vez de acelerar sites e serviços.
  
• TTL baixo proporciona tranqüilidade.
  
• As pessoas inicialmente definem TTLs baixos para teste e esquecem de alterá-los.

Não incluí "failover" na lista, pois tudo isso é menos relevante. Se você precisar redirecionar os usuários para outra rede apenas para exibir a página de erro, quando absolutamente tudo estiver quebrado, provavelmente será aceitável um atraso de mais de 1 minuto.

Além disso, o minuto TTL significa que, se os servidores DNS autorizados estiverem bloqueados por mais de um 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 invasão. Por outro lado, com TTLs razoáveis, muitos clientes continuarão usando a configuração anterior e nunca perceberão nada.

Os serviços CDN e os balanceadores de carga são os principais responsáveis ​​pelos baixos TTLs, especialmente quando combinam CNAME com pequenos TTLs e registros com TTLs igualmente pequenos (mas independentes):

  $ drill raw.githubusercontent.com
 raw.githubusercontent.com.  9 NO CNAME github.map.fastly.net.
 github.map.fastly.net.  20 EM A 151.101.128.133
 github.map.fastly.net.  20 EM A 151.101.192.133
 github.map.fastly.net.  20 EM A 151.101.0.133
 github.map.fastly.net.  20 EM A 151.101.64.133 

Sempre que um CNAME ou qualquer um dos registros A expirar, você deverá enviar uma nova solicitação. Ambos têm um TTL de 30 segundos, mas não corresponde. O TTL médio real será de 15 segundos.

Mas espera! Ainda pior. Alguns resolvedores se comportam muito mal nessa situação com dois TTLs baixos associados:

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

O resolvedor Level3 provavelmente funciona no BIND. Se você continuar enviando essa solicitação, sempre será retornado um TTL 1. Essencialmente, raw.githubusercontent.com nunca raw.githubusercontent.com 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 NO CNAME detectportal.prod.mozaws.net.
 detectportal.prod.mozaws.net.  26 NO CNAME detectportal.firefox.com-v2.edgesuite.net.
 detectportal.firefox.com-v2.edgesuite.net.  10668 NO CNAME a1089.dscd.akamai.net.
 a1089.dscd.akamai.net.  10 EM A 104.123.50.106
 a1089.dscd.akamai.net.  10 EM A 104.123.50.88 

Pelo menos três registros CNAME. Aw. Um deles tem um TTL decente, mas é completamente inútil. Em outros CNAMEs, o TTL inicial é de 60 segundos, mas para os domínios akamai.net TTL máximo é de 20 segundos e nenhum deles está em fase.

E os domínios que pesquisam constantemente os dispositivos Apple?

  $ drill 1-courier.push.apple.com @ 4.2.2.2
 1-courier.push.apple.com.  1253 NO CNAME 1.courier-push-apple.com.akadns.net.
 1.courier-push-apple.com.akadns.net.  1 EM CNAME gb-courier-4.push-apple.com.akadns.net.
 gb-courier-4.push-apple.com.akadns.net.  1 EM A 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net.  1 EM A 17.57.146.85 

O mesmo problema que o Firefox tem e o TTL fica travado por 1 segundo na maioria das vezes ao usar o resolvedor Level3.

Dropbox?

  $ drill client.dropbox.com @ 8.8.8.8
 client.dropbox.com.  7 EM CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  59 EM A 162.125.67.3

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

safebrowsing.googleapis.com um TTL de 60 segundos, assim como nos domínios do Facebook. E, novamente, do ponto de vista do cliente, esses valores são reduzidos pela metade.

Que tal definir um TTL mínimo?

Usando o nome, tipo de solicitação, TTL e o carimbo de data / hora salvo originalmente, escrevi um script para simular 1,5 milhão de solicitações passando por um resolvedor de cache, a fim de estimar a quantidade de solicitações extras enviadas devido a uma entrada de cache expirada.

47,4% dos pedidos foram feitos após a expiração do registro existente. Isso é irracionalmente alto.

Qual será o efeito no armazenamento em cache se o TTL mínimo estiver definido?



O eixo X é o valor TTL mínimo. Registros com TTLs de origem acima desse valor não são afetados.

Eixo Y - porcentagem de solicitações de um cliente que já possui um registro em cache, mas expirou e faz uma nova solicitação.

A porcentagem de solicitações "extras" é reduzida de 47% para 36%, basta definir o TTL mínimo em 5 minutos. Ao definir o TTL mínimo em 15 minutos, o número dessas solicitações é reduzido para 29%. Um TTL mínimo de 1 hora os reduz para 17%. A grande diferença!

Que tal não mudar nada no lado do servidor, mas definir o TTL mínimo nos caches DNS do cliente (roteadores, resolvedores locais)?



O número de solicitações necessárias é reduzido de 47% para 34% ao definir o TTL mínimo em 5 minutos, para 25% com um mínimo de 15 minutos e até 13% com um mínimo de 1 hora. Talvez o valor ideal seja 40 minutos.

O impacto dessa mudança mínima é enorme.

Quais são as implicações?

Obviamente, o serviço pode ser transferido 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 suficientemente pequeno ajuda a fazer essa transição sem problemas. Porém, com a transição para uma nova infraestrutura, ninguém espera que os clientes mudem para novos registros DNS dentro de 1 minuto, 5 minutos ou 15 minutos. Definir uma vida útil mínima de 40 minutos em vez de 5 minutos não impedirá que os usuários acessem o serviço.

No entanto, isso reduzirá significativamente a latência e aumentará a confidencialidade e a confiabilidade, evitando solicitações desnecessárias.

Obviamente, os RFCs dizem que você precisa aplicar estritamente o TTL. Mas a realidade é que o sistema DNS se tornou muito ineficiente.

Se você trabalha com servidores DNS autoritativos, verifique seu TTL. Você realmente precisa de valores ridiculamente baixos?

Obviamente, existem boas razões para definir pequenos TTLs para registros DNS. Mas não para 75% do tráfego DNS, que permanece praticamente inalterado.

E se, por algum motivo, você realmente precisar usar TTL baixo para DNS, ao mesmo tempo, verifique se o cache não está ativado no seu site. Pelas mesmas razões.

Se você possui um cache DNS local, como dnscrypt-proxy , que permite definir o TTL mínimo, use esta função. Isso é normal. Nada de ruim vai acontecer. Defina o TTL mínimo entre aproximadamente 40 minutos (2400 segundos) e 1 hora. Um intervalo bastante razoável.