Como corrigir uma consulta DNS lenta

O que uma consulta lenta está medindo

Carregar uma página começa com uma consulta de nome, depois uma conexão TCP, depois um handshake TLS, e por fim o tempo de processamento do próprio servidor. Só o primeiro item é DNS, e é o único que você muitas vezes consegue melhorar sem tocar no site.

Dois números se confundem aqui. Uma consulta em cache custa quase nada, porque a resposta já está na sua máquina ou a um salto de distância. Uma consulta fria pode envolver uma pergunta à raiz, outra ao domínio de topo e outra aos servidores de nomes do próprio domínio, cada uma delas uma ida e volta pela distância que separa você desses servidores. Menos de 20 ms com cache quente e menos de 100 ms a frio não chamam atenção. Qualquer coisa perto de um segundo significa que um dos saltos está longe, sobrecarregado ou estourando o tempo e sendo repetido.

As páginas modernas pioram isso por terem muitos nomes de host. Fontes, analytics, imagens e widgets de pagamento precisam cada um da sua consulta, e um navegador que resolve dez nomes de host a 300 ms cada gastou três segundos em DNS antes de renderizar qualquer coisa útil.

Confirme que o DNS é a parte lenta

Meça antes de mudar qualquer coisa. O comando único mais limpo divide uma requisição em suas fases:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Se time_namelookup for uma fração pequena do total, o DNS não é o seu problema e você deveria estar lendo sobre tempo de resposta do servidor. Se for um terço ou mais, siga em frente. Para a consulta isolada, o dig já imprime o tempo decorrido:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

No Windows, o PowerShell dá a mesma leitura:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Compare o seu resolvedor padrão com os resolvedores públicos. Uma diferença grande diz que a correção é do seu lado. Tempos parecidos em todos apontam para os servidores de nomes do próprio domínio.

Um resultado descarta este guia por completo. Se um resolvedor responde na hora com NXDOMAIN, o nome não está publicado e você está diante de outro problema, descrito em DNS_PROBE_FINISHED_NXDOMAIN.

Por que acontece

• Um resolvedor distante. Serviços públicos usam anycast, então o mesmo endereço responde de um local próximo. O resolvedor de um provedor ou um único servidor de escritório não faz isso, e toda consulta paga a ida e volta completa.
• O primeiro servidor da lista está morto. O cliente espera o tempo limite inteiro e só então pergunta ao segundo. Em sistemas com glibc o padrão são 5 segundos até a primeira repetição, exatamente a pausa que as pessoas descrevem como "trava e depois carrega".
• TTLs muito baixos. Um TTL de 30 ou 60 segundos faz quase todo visitante pagar por uma consulta nova, porque a cópia em cache já expirou.
• Cadeias longas de CNAME. Cada elo é mais uma consulta. Cadeias de três ou quatro são comuns por trás de CDNs e ferramentas de marketing.
• Servidores de nomes autoritativos lentos. Um provedor de DNS com poucas localizações responde rápido para parte do mundo e devagar para o resto.
• Validação DNSSEC. Validar uma cadeia acrescenta consultas. Normalmente é barato, mas uma cadeia parcialmente quebrada causa repetições que parecem lentidão.
• Domínios de busca. Um resolvedor configurado com sufixos tenta example.com.corp.local antes de example.com, gastando uma consulta perdida em cada sufixo primeiro.
• Consultas AAAA sem IPv6. O sistema pede os dois tipos de registro e espera pela resposta que não pode usar.
• Uma VPN ou proxy de filtragem enviando todas as consultas por um túnel até um resolvedor em outro continente.
• Um roteador atuando como encaminhador com cache minúsculo e CPU fraca.

Como corrigir

No seu dispositivo

1. Limpe os caches para que suas medições sejam honestas: ipconfig /flushdns no Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder no macOS, sudo resolvectl flush-caches no Linux.
2. Olhe quais servidores estão configurados e em que ordem: Get-DnsClientServerAddress, scutil --dns ou resolvectl status. Remova qualquer entrada que não responde mais, já que uma primeira entrada morta custa o tempo limite inteiro em toda consulta fria.
3. No Linux, encurte a espera enquanto investiga adicionando options timeout:2 attempts:2 a /etc/resolv.conf, e corte os sufixos search que não usa.
4. Desconecte a VPN e meça de novo. Se o número cair pela metade, o túnel é a causa e a configuração de resolvedor dele é o que mudar.

Na sua rede

1. Defina o resolvedor no DHCP do roteador em vez de dispositivo por dispositivo, para que todo cliente receba o mesmo par rápido.
2. Dê ao encaminhador do próprio roteador um resolvedor público como upstream em vez do padrão do provedor, ou contorne o encaminhador entregando os endereços públicos diretamente aos clientes.
3. Em uma rede corporativa com servidor DNS próprio, confira se ele encaminha em vez de fazer recursão completa a partir de um único site, e se o cache dele é grande o bastante para sobreviver ao dia de trabalho.

No seu próprio domínio

1. Aumente os TTLs dos registros que raramente mudam. Cinco minutos é um piso razoável para um registro que você talvez precise mover rápido; uma hora ou um dia serve para tudo que é estável.
2. Achate as cadeias de CNAME onde der. Aponte o registro para o destino final em vez de uma sequência de apelidos: dig www.example.com CNAME +short mostra quão profunda é a sua.
3. Use um provedor de DNS com servidores de nomes anycast, e mantenha pelo menos dois servidores de nomes em redes separadas.
4. Confira se o DNSSEC valida. Compare uma consulta normal com uma que pula a validação: dig example.com @1.1.1.1 contra dig +cd example.com @1.1.1.1. Uma diferença grande, ou um SERVFAIL só na primeira, significa que a cadeia está quebrada.

Verifique de fora

Os seus próprios tempos descrevem uma rede em um momento, que é a amostra menos útil possível. Um resolvedor que está a 8 ms de você pode estar a 400 ms de um cliente em outra região, e é esse cliente que está reclamando.

Comece medindo os servidores autoritativos diretamente, o que elimina todo cache entre você e a origem:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

A saída de +trace percorre a delegação um passo por vez, então um salto que trava fica visível em vez de diluído em uma média. Depois rode a verificação de consulta DNS, que resolve o nome a partir de pontos de verificação em países diferentes e informa cada um separadamente. Essa é a medição que você não consegue fazer de um notebook: ela mostra se os seus servidores de nomes estão lentos em todo lugar, o que aponta para o provedor, ou lentos a partir de um continente, o que aponta para a cobertura de rede dele. Se algumas localizações devolvem uma resposta diferente em vez de mais lenta, a questão é propagação, tratada em como verificar a propagação de DNS.

Latência que vai piorando em vez de quebrar

A latência de DNS raramente quebra de forma óbvia. Ela vai piorando aos poucos: um servidor de nomes perde uma localização, um TTL é reduzido durante uma migração e nunca mais é elevado, e seis semanas depois o site parece lento por motivos que ninguém consegue apontar. Uma medição única não mostra tendência, e é por isso que vale registrar o tempo de consulta em intervalos regulares a partir das regiões onde estão os seus visitantes. A HostTracker monitora sites desde 2004 e hoje acompanha mais de 500.000 sites a partir de pontos de verificação em 158 cidades, guardando o histórico que torna uma piora lenta visível. Os outros guias daqui estão no grupo de correções, e o caso de falha em que nada volta é servidor DNS não está respondendo.