Imagine que o endereço do servidor de um domínio foi alterado: em casa abre o site novo, mas o telefone ainda se conecta ao servidor antigo. Mesmo usando o mesmo nome, os aparelhos podem apresentar resultados temporariamente diferentes se passarem por caches DNS distintos. O cache HTTP que reutiliza páginas baixadas e o cache DNS que ajuda a encontrar um endereço de conexão exigem verificações diferentes.
Este artigo acompanha o host fictício de biblioteca www.library.example para explicar resolução de nomes e cache. Os nomes e horários são exemplos didáticos, sem medições das respostas de um serviço real. O objetivo é separar como o DNS fornece endereços, por que mudanças podem demorar a aparecer e quais falhas ocorrem depois da resolução.
1. O DNS oferece diferentes tipos de resposta para cada nome
O DNS fornece informações associadas a nomes de domínio em registros de tipos diferentes. A representa um endereço IPv4 e AAAA um endereço IPv6; um nome pode ter vários endereços. CNAME é um alias que aponta para outro nome, MX identifica um servidor que recebe correio e NS um servidor de nomes autoritativo para a zona. Assim, consultar o mesmo nome pode gerar respostas diferentes conforme o tipo de registro solicitado.
Como explica a documentação de registros DNS da Cloudflare, o valor de um CNAME é outro nome, não um endereço IP. Obter um endereço pode exigir resolver também esse nome. Em https://www.library.example/books, o nome de host tratado pelo DNS é www.library.example. Nem o caminho /books nem o corpo da página são registrados no DNS. Configurar um CNAME não cria automaticamente um redirecionamento HTTP que mude a barra de endereços do navegador.
2. Como um resolvedor recursivo encontra os servidores autoritativos
A função de resolução de nomes do aparelho normalmente consulta o resolvedor recursivo configurado. Ele utiliza as informações disponíveis em cache; se faltarem, consulta outros servidores DNS e devolve a resposta final ou um erro. O padrão de terminologia DNS RFC 9499 distingue essa resolução em nome do cliente do papel do servidor autoritativo, que possui as informações da sua zona. A origem de uma resposta deve ser interpretada conforme o papel do servidor.
Num percurso simplificado sem cache nem intermediários, o resolvedor recebe da raiz uma referência aos servidores do domínio de nível superior e, deles, uma referência aos servidores autoritativos da zona desejada. Do servidor autoritativo final obtém o registro ou alias procurado. Um único servidor raiz não guarda os endereços IP de todos os sites. Na prática, a resolução pode começar por uma delegação já armazenada ou ser encaminhada a outro resolvedor, sem repetir obrigatoriamente toda a sequência em cada visita.
3. TTL é tempo restante em cache, não um relógio mundial
O TTL de um registro informa seu tempo de vida em cache, em segundos. Numa resposta comum de cache, o tempo restante diminui enquanto o registro está armazenado. Se um resolvedor guardar um endereço às 10:00 com TTL de 300 segundos, a resposta da mesma cópia às 10:02 terá cerca de 180 segundos restantes. A tabela pressupõe um único resolvedor sem nova consulta, atualização antecipada ou fornecimento de respostas vencidas.
| Horário fictício | Endereço no servidor autoritativo | Ação deste resolvedor |
|---|---|---|
| 10:00 | Endereço antigo | Armazena o endereço antigo com TTL de 300 segundos |
| 10:01 | Alterado para o novo endereço | A cópia armazenada ainda tem 240 segundos |
| 10:03 | Endereço novo | Pode reutilizar o antigo durante os 120 segundos restantes |
| Primeira consulta após 10:05 | Endereço novo | Supõe-se que consulte novamente e obtenha o endereço novo em vez de usar a cópia vencida |
Outros resolvedores podem ter armazenado o registro mais tarde ou nunca tê-lo visto. Seus momentos de atualização diferem, então um TTL não determina quando todos os usuários do mundo mudarão simultaneamente. O cache também pode descartar dados antes do vencimento, e atualizar uma página não apaga a cópia de um resolvedor compartilhado. TTL ajuda a entender a reutilização de respostas DNS; não limita o tempo de toda a conexão web ou da atualização da tela.
4. Quando reduzir o TTL e como a ausência é armazenada
Um cache que recebeu o endereço antigo com TTL de 3 600 segundos não é informado imediatamente quando o operador reduz esse valor para 60 segundos. Para uma mudança planejada, ajuste o TTL antecipadamente e considere o tempo restante de respostas guardadas com a duração anterior mais longa. Um TTL menor pode aumentar a frequência de verificação, mas também a carga de consultas e a dependência dos servidores autoritativos. Avalie a mudança e a resposta a falhas em conjunto, em vez de impor o mesmo número curto a todos os serviços.
NXDOMAIN, que indica um nome inexistente, e NODATA, que indica um nome existente sem registros do tipo solicitado, também podem ser armazenados em cache. O padrão de cache negativo RFC 2308 define essa duração pelo menor valor entre o TTL do registro SOA do servidor autoritativo e o campo MINIMUM do SOA. Assim, uma resposta anterior de ausência pode permanecer logo depois de adicionar um host. Presumir que ela dura o mesmo que o TTL do novo registro A pode esconder a causa.
5. Verifique mantendo o mesmo nome, tipo e servidor
Registre o nome exato consultado, o tipo, como A ou AAAA, o servidor DNS consultado e o horário. Se dig estiver instalado, dig example.com A permite especificar nome e tipo. Ao investigar um problema real, substitua example.com pelo host que deseja verificar. O comando exemplifica um procedimento; não foi executado nem usado para medir tempos de resposta neste artigo.
Observe o estado da resposta junto aos nomes, tipos, valores e TTL presentes em ANSWER. Ao repetir a mesma consulta no mesmo resolvedor, veja se o TTL diminui, sem tratar imediatamente um aumento como erro. Pode ter ocorrido uma atualização antecipada ou a resposta pode vir de outro nó de cache. Registrar A e AAAA separadamente ajuda a identificar qual família de endereços apresenta diferenças.
Se você administra a zona, compare a resposta do resolvedor recursivo com a do servidor autoritativo para o mesmo nome e tipo. Se diferirem, verifique sucessivamente o tempo restante de cache, a consistência entre servidores autoritativos e a delegação. Não generalize a resposta de um resolvedor público para todos os usuários. O DNS interno de uma empresa ou as configurações DNS próprias do navegador podem mudar o caminho da consulta; registre também o ambiente de conexão.
6. Separe erros DNS, erros de conexão e exceções
NXDOMAIN responde que o nome não existe e NODATA indica a ausência do tipo de registro solicitado. SERVFAIL, por outro lado, indica que o servidor não conseguiu processar a consulta; um tempo de espera esgotado significa que nenhuma resposta chegou no prazo definido. Nem todos esses casos significam que o domínio foi excluído. Preserve primeiro se houve um código de resposta e qual servidor foi consultado para decidir o próximo passo.
Uma resposta antiga depois do vencimento do TTL nem sempre viola as regras. O método serve-stale da RFC 8767 define como aproveitar informações vencidas para melhorar a disponibilidade quando excepcionalmente não é possível atualizá-las nos servidores autoritativos. Isso não significa que todos os resolvedores usem a mesma configuração. Verifique o comportamento do resolvedor usado, em vez de deduzir um prazo garantido de propagação a partir de um único TTL.
Por fim, resolver um endereço corretamente não garante acesso ao site. A rede até esse endereço, o certificado TLS, o servidor web e a aplicação são etapas separadas. Se o DNS retorna o endereço esperado, mas a página não abre, prossiga para a investigação da conexão seguinte. Registrar separadamente a resposta DNS e a resposta web ajuda a localizar a falha antes de apagar caches de páginas ou mudar configurações DNS sem critério.