Domain Name System (DNS) latência é um componente chave para ter uma boa experiência online. E para minimizar a latência DNS, escolher cuidadosamente servidores DNS e relés de anonimização desempenha um papel importante.
mas a melhor maneira de minimizar a latência é evitar enviar consultas inúteis para começar. É por isso que o DNS foi concebido, desde o primeiro dia, para ser um protocolo muito acessível. Os registros individuais têm um tempo para viver (TTL), originalmente definido pelos administradores de zona, e resolvers usam esta informação para manter esses registros em memória para evitar tráfego desnecessário.o caching é eficiente? Um estudo rápido que fiz há alguns anos mostrou que havia espaço para melhorias. Hoje, quero dar uma nova vista de olhos à situação actual.
para fazer isso, eu patched um servidor DNS criptografado para armazenar o TTL original de uma resposta, definido como o TTL mínimo de seus registros, para cada consulta recebida. Isso nos dá uma boa visão geral da distribuição TTL do tráfego real, mas também conta a popularidade de consultas individuais.
essa versão remendada foi deixada para correr por um par de horas. O conjunto de dados resultante é composto por 1,583,579 (nome, qtype, TTL, timestamp) tuplas. Aqui é o total TTL de distribuição (o eixo X é o TTL em segundos):
além de um aumento negligenciável de 86,400 (principalmente para registros SOA), é bastante óbvio que TTLs estão na faixa baixa. Vamos ampliar:
tudo Bem, TTLs acima de 1 hora de são estatisticamente insignificantes. Vamos focar no 0-3,600 intervalo:
E onde a maioria TTLs sentar-se entre os 0 e 15 minutos:
A grande maioria é entre 0 e 5 minutos:
This is not great. A distribuição cumulativa pode tornar a questão ainda mais óbvia:
Half the Internet has a 1-minute TTL or less, and three-quarters have a 5-minute TTL or less.mas espera, isto é realmente pior. Estes são TTLS como definido por servidores autorizados. No entanto, TTLs recuperados dos resolvers clientes (por exemplo, roteadores, caches locais) Obter um TTL que resolvers upstream decrement a cada segundo. Assim, em média, a duração real de um cliente pode usar uma entrada em cache antes de exigir uma nova consulta é metade do TTL original.
talvez estes TTLS muito baixos afetem apenas consultas incomuns, e não Sites populares e APIs. Let’s take a look:
infelizmente, as consultas mais populares são também as mais inúteis para cache. Vamos ampliar:
veredito: it’s really bad, or rather it was already bad, and it’s gotten worse. Cache DNS tornou-se quase inútil. Com menos pessoas usando a resolução DNS do seu ISP (por boas razões), o aumento da latência torna-se mais perceptível. Cache DNS tornou-se apenas útil para o conteúdo que ninguém visita. Além disso, note que o software pode interpretar o TTLS baixo de forma diferente.porquê?
porque é que os registos DNS são estabelecidos com TTLs tão baixos?
- Legacy load balancers are left with default settings.
- A lenda urbana de que o balanceamento de carga baseado no DNS depende do TTLs (não depende).administradores querendo que suas alterações sejam aplicadas imediatamente, porque pode exigir menos trabalho de planejamento.
- Como administrador de DNS ou load-balancer, seu dever é implementar eficientemente a configuração que as pessoas pedem, não fazer sites e serviços rápidos.os TTLs Baixos dão paz de espírito.
não estou a incluir “for failover” nessa lista, uma vez que esta se tornou cada vez menos relevante. Se a intenção é redirecionar os usuários para uma rede diferente apenas para exibir uma página de baleia falha quando absolutamente tudo o resto está em chamas, ter mais de um minuto de atraso é provavelmente aceitável.
CDNs e de carga, balanceadores de carga são parte da culpa, especialmente quando eles combinam registros CNAME com curto TTLs, com registros também ter curtos (mas independente) TTLs:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
Uma nova consulta precisa ser enviada sempre que o CNAME ou qualquer dos registros expiram. Ambos têm um TTL de 30 segundos, mas não estão em fase. A média real de TTL será de 15 segundos.mas espera! Isto é pior. Alguns resolvers se comportam muito mal em uma situação de baixo-TTL-CNAME+baixo-TTL-registros:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Este é o resolver Do Nível 3, que, eu acho, está executando BIND. Se você continuar enviando essa consulta, o TTL retornado será sempre 1. Essencialmente, raw.githubusercontent.com nunca serão apanhados.
Aqui está outro exemplo de uma situação low-TTL-CNAME+low-TTL-records, com um nome muito popular:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
No less than three CNAME records. Ai. Um deles tem um TTL decente, mas é totalmente inútil. Outros CNAMEs têm um TTL original de 60 segundos; o akamai.net os nomes têm um TTL máximo de 20 segundos e nada disso está em fase.que tal um que os seus dispositivos da Apple pesquisem constantemente?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
a mesma configuração que o Firefox e o TTL está preso a 1 A maior parte do tempo ao usar o Resolução do Level3.e o Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com tem um TTL de 60 segundos. Os nomes do Facebook têm um TTL de 60 segundos. E, mais uma vez, do ponto de vista do cliente, estes valores devem ser reduzidos para metade.
que tal definir um TTL mínimo?
Usando o nome, tipo de consulta, TTL e timestamp inicialmente armazenados, eu escrevi um script que simula as mais de 1,5 milhões de consultas que passam por um resolvedor de cache para estimar quantas consultas foram enviadas devido a um item de cache expirado. 47,4% das consultas foram feitas após a expiração de uma entrada existente em cache. Isto é demasiado alto.qual seria o impacto no caching se um TTL mínimo fosse definido?
o eixo X é o TTL mínimo que foi definido. Os registos cujo TTL original era superior a este valor não foram afectados. O eixo Y é a porcentagem de consultas feitas por um cliente que já tinha uma entrada em cache, mas uma nova consulta foi feita e a entrada em cache tinha expirado.
O número de consultas cai de 47% Para 36% apenas definindo um TTL mínimo de 5 minutos. A definição de um TTL mínimo de 15 minutos faz com que o número de consultas necessárias caia para 29%. Um TTL mínimo de 1 hora faz com que caia para 17%. É uma diferença significativa!
Que tal não mudar nada do lado do servidor, mas ter caches cliente DNS (roteadores, resolvedores locais e caches…) definir um TTL mínimo em vez disso?
O número de consultas de gotas de 47% para 34% através da definição de um TTL mínimo de 5 minutos, para 25%, com 15 minutos no mínimo, e para 13%, com 1 hora no mínimo. 40 minutos, talvez um bom lugar. O impacto dessa mudança mínima é enorme.quais são as implicações?
claro, um serviço pode mudar para um novo provedor de nuvem, um novo servidor, uma nova rede, exigindo que os clientes usem registros DNS atualizados. E ter TTLs razoavelmente baixos ajuda a tornar a transição livre de atrito. No entanto, ninguém que se mude para uma nova infra-estrutura vai esperar que os clientes usem os novos registos DNS dentro de 1 minuto, 5 minutos ou 15 minutos. A definição de um TTL mínimo de 40 minutos em vez de 5 minutos não vai impedir os usuários de acessar o serviço. No entanto, irá reduzir drasticamente a latência, e melhorar a privacidade (mais consultas = mais oportunidades de rastreamento) e confiabilidade, evitando consultas desnecessárias.é claro que os RFCs dizem que as TTLs devem ser rigorosamente respeitadas. Mas a realidade é que o DNS tornou-se ineficiente.
Se estiver a operar servidores de DNS autorizados, por favor reveja o seu TTLs. Precisas mesmo que isto seja ridiculamente baixo?
Read: How to choose DNS TTL values
Sure, there are valid reasons to use low DNS TTLs. Mas não para 75% da Internet para servir conteúdo que é principalmente imutável, mas inútil para cache. E se, por quaisquer razões, você realmente precisa usar DNS TTLS baixos, também certifique-se de que o cache não funciona em seu site também. Pelas mesmas razões.
Se utilizar uma ‘cache’ DNS local, como o dnscrypt-proxy, que permite definir o TTLs mínimo, use essa funcionalidade. Não faz mal. Nada de mal vai acontecer. Defina esse TTL mínimo para algo entre 40 minutos (2400 segundos) e 1 hora; este é um intervalo perfeitamente razoável.
00f.net