O que é um cache de DNS, e por quanto tempo os registros ficam nele?

Onde uma resposta de DNS realmente fica em cache?

Uma única consulta passa por vários caches antes que você perceba qualquer coisa, e cada um guarda sua própria cópia pelo seu próprio tempo:

• O navegador. Chrome, Edge e Firefox mantêm cada um seu próprio pequeno cache de DNS, separado do sistema operacional. O do Chrome fica visível em chrome://net-internals/#dns, e limpá-lo afeta só aquele navegador, não o resto da máquina.
• O resolvedor stub do sistema operacional. O Windows roda o serviço DNS Client e guarda as respostas que você lista com ipconfig /displaydns; o macOS faz cache através do mDNSResponder; a maioria dos desktops Linux roda o systemd-resolved, um resolvedor stub local com cache que você consulta com resolvectl. Esse é um cache de verdade, com sua própria contagem regressiva de TTL, não apenas uma cópia do que o navegador tem.
• O roteador. A maioria dos roteadores domésticos roda um pequeno encaminhador de DNS que responde a partir do próprio cache antes de repassar a consulta adiante, o que explica por que reiniciar o roteador às vezes "resolve" um problema de DNS que na verdade estava em outro lugar.
• O resolvedor recursivo. O resolvedor do seu provedor de internet, ou um público, atende a maior parte das consultas na internet e mantém o maior e mais compartilhado cache. Uma vez que ele tem uma resposta, todo dispositivo que pergunta a ele recebe a cópia em cache até ela expirar.

Cada camada é independente. Limpar o cache do seu notebook não faz nada ao cache que o seu roteador ou o seu provedor ainda estão guardando, e não muda nada para a máquina de mais ninguém.

O que é um TTL, e quem realmente o respeita?

Todo registro de DNS carrega um time to live: um número em segundos, definido por quem administra a zona, que diz a um resolvedor por quanto tempo ele pode reutilizar a resposta antes de perguntar de novo. A RFC 1035 o define como o intervalo que um registro "pode ficar em cache antes que a fonte da informação deva ser consultada de novo", e um TTL igual a zero significa que a resposta nunca deve ser guardada em cache.

Todo cache na cadeia, navegador, resolvedor stub, roteador, resolvedor recursivo, deveria respeitar esse número, contando a partir do momento em que buscou o registro pela primeira vez. Na prática, alguns resolvedores de provedores de internet aplicam o próprio piso por cima disso, geralmente uma hora ou mais, independentemente do que a zona diz que o TTL deveria ser. É por isso que baixar um TTL para acelerar uma mudança futura ajuda a maioria dos resolvedores, mas não é garantia para todos eles.

O que é cache negativo, e por que um registro recém-criado pode continuar "não encontrado"?

Um resolvedor não guarda em cache só os registros que existem. Se uma consulta volta com "esse nome não existe" (NXDOMAIN) ou sem nenhum registro do tipo pedido, essa falha também fica em cache, um comportamento chamado cache negativo. A RFC 2308 define o tempo de vida do cache negativo a partir do campo mínimo do registro SOA, e a RFC 9520 agora torna obrigatório, em vez de opcional, que um resolvedor em conformidade guarde essa falha em cache.

Esse é o mecanismo por trás de um problema conhecido: você cria um novo subdomínio, consulta cedo demais, recebe NXDOMAIN, e o resolvedor guarda "não existe" pelo tempo do TTL negativo da zona, mesmo que o registro já exista agora. O Windows deixa os dois tipos de entrada visíveis separadamente: ipconfig /displaydns lista tanto as respostas positivas quanto as negativas, e ipconfig /flushdns descarta explicitamente as entradas de cache negativas como parte da limpeza do cache.

Por que um site resolve para você e não para outra pessoa?

Porque não existe um único cache compartilhado. Duas pessoas perguntando a dois resolvedores diferentes, ou perguntando ao mesmo resolvedor em dois momentos diferentes, podem receber duas respostas diferentes para o mesmo nome. A cópia de um resolvedor pode ainda estar fresca de uma consulta de uma hora atrás; outro pode nunca ter visto aquele nome e ir buscar o valor atual. Nenhum dos dois está errado, eles só estão em relógios diferentes. Se isso está acontecendo logo depois que você mudou um registro, como verificar a propagação de DNS mostra como comparar vários resolvedores lado a lado e ler quanto tempo falta para cada um.

Como você lê o TTL de um registro que ainda está em cache?

Consulte o nome diretamente e mantenha a saída completa em vez da forma curta:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

O número antes do tipo de registro, 847 neste exemplo, são os segundos restantes até a cópia daquele resolvedor específico expirar; não é o TTL original do registro, que só o servidor autoritativo pode dizer com certeza. Rode a mesma consulta de novo alguns segundos depois e o número terá caído aproximadamente essa quantidade de segundos, confirmando que você está lendo uma contagem regressiva ao vivo, não uma configuração estática. Se um nome simplesmente não resolver, em vez de resolver com um número baixo, isso é uma falha diferente: como limpar o cache de DNS cobre limpar o seu próprio cache primeiro, e o que um resolvedor de DNS realmente faz cobre o que acontece a seguir na cadeia quando o seu próprio cache não é o problema.

Um cache explica por que um visitante vê uma mudança imediatamente e outro não; ele não explica um registro que nunca atualiza em lugar nenhum. Rode uma consulta ao vivo com a ferramenta de consulta DNS para ver a resposta atual vinda de fora da sua própria rede, e se o site precisa continuar acessível seguindo uma agenda em vez de verificado uma única vez, é para isso que serve o monitoramento distribuído a partir de vários pontos de verificação. O HostTracker monitora sites desde 2004, hoje observa mais de 500.000 sites a partir de mais de 300 pontos de verificação em 158 cidades, e avisa por e-mail, SMS, chamada de voz, Slack, Telegram e outros quando uma verificação falha, incluindo uma verificação que espera um endereço IP específico e avisa no momento em que a resposta muda.

Perguntas frequentes

Um cache de DNS cheio deixa meu computador lento?

Não. Um cache de DNS é uma tabela pequena de nomes e endereços, geralmente algumas centenas de entradas no máximo, e procurar uma delas não custa nada mensurável. Se as consultas parecem lentas, o cache em si não é a causa; um resolvedor distante ou sobrecarregado costuma ser.

Limpar o meu cache resolve para outras pessoas?

Não. ipconfig /flushdns, dscacheutil -flushcache e resolvectl flush-caches só limpam o cache na máquina onde você os roda. Todo mundo continua lendo do próprio navegador, do próprio roteador e do próprio resolvedor, cada um no seu próprio relógio.

Um cache de DNS é a mesma coisa que um cache de CDN?

Não, embora os dois sejam confundidos. Um cache de DNS guarda a resposta para "qual é o endereço IP deste nome". Um cache de CDN guarda o conteúdo da página ou do arquivo em si, em um servidor perto do visitante. Limpar um não tem efeito nenhum sobre o outro.

Posso definir meu próprio TTL se eu não administro o domínio?

Não. O TTL é uma propriedade do registro, definida na zona autoritativa por quem administra o DNS do domínio. Como visitante, a única alavanca que você tem é escolher consultar um resolvedor que respeite um TTL curto em vez de um que imponha o próprio piso.

Por que o TTL que eu vejo muda a cada consulta?

Porque você está perguntando a um resolvedor diferente, ou ao mesmo resolvedor em um momento diferente da sua contagem regressiva. Consulte o servidor de nomes autoritativo diretamente com dig example.com @ns1.yourdns.example para ver o TTL como ele foi originalmente definido, sem nada já contado.