Quando você digita o endereço de um site no navegador, o Windows precisa descobrir para qual endereço IP aquela conexão deve ser enviada. Para isso, normalmente entra em cena o DNS, sistema responsável por transformar nomes como exemplo.com em informações que computadores conseguem utilizar para localizar serviços na rede.
Mas existe um detalhe importante: o Windows não precisa necessariamente consultar um servidor DNS toda vez que um programa procura o mesmo nome.
O sistema mantém um cache DNS local.
Esse cache pode armazenar temporariamente resultados de consultas anteriores, permitindo que determinadas resoluções sejam reutilizadas sem repetir imediatamente todo o processo.
É justamente aí que encontramos um dos comandos de diagnóstico de rede mais interessantes do Windows:
ipconfig /displaydns
Execute o comando e provavelmente aparecerá uma quantidade enorme de informações.
Nomes conhecidos.
Domínios que você não lembra de ter acessado.
Entradas IPv4.
Entradas IPv6.
Valores numéricos.
Registros diferentes.
E talvez até domínios que aparentemente não possuem nenhuma relação com o site que você acabou de abrir.
Então surgem várias perguntas:
O que exatamente está armazenado ali?
Por que existem tantos domínios?
Quanto tempo essas informações permanecem no computador?
Um domínio presente no cache significa que alguém visitou aquele site?
Por que aparecem endereços IPv6 mesmo quando você nunca digitou um endereço IPv6?
O que acontece quando executamos ipconfig /flushdns?
Neste guia da VMIA, vamos abrir esse cache e entender o que cada informação significa.
Primeiro: o que é DNS?
DNS significa:
Domain Name System
Em uma explicação simplificada, ele permite associar nomes a diferentes tipos de informações utilizadas na comunicação de rede.
Quando você acessa:
www.exemplo.com
o computador precisa descobrir informações necessárias para alcançar o serviço correspondente.
Entre elas pode estar um endereço IPv4 como:
203.0.113.10
ou um endereço IPv6.
O DNS não se limita apenas a “converter nome em IP”. Ele possui diferentes tipos de registros, capazes de representar informações distintas.
Entre os tipos conhecidos estão:
- A;
- AAAA;
- CNAME;
- MX;
- PTR;
- TXT;
- SRV.
Nem todos possuem a mesma finalidade.
Para entender o cache DNS do Windows, começaremos principalmente pelos registros diretamente relacionados às resoluções feitas pelo computador.
Por que o Windows mantém um cache DNS?
Imagine que um navegador precise consultar o DNS toda vez que carregar qualquer recurso associado a um nome já resolvido segundos antes.
Seriam realizadas muitas consultas repetidas desnecessariamente.
O cache permite reutilizar determinadas respostas durante um período.
Uma sequência simplificada pode ser representada assim:
Programa solicita um nome
↓
Windows verifica informações disponíveis localmente
↓
Se necessário, ocorre uma consulta DNS
↓
Resposta é recebida
↓
Informação pode ser armazenada temporariamente
↓
Solicitações posteriores podem aproveitar o resultado enquanto ele for válido
Esse mecanismo reduz consultas repetidas e pode melhorar a eficiência da resolução de nomes.
Mas a palavra mais importante aqui é:
temporariamente.
O cache DNS não deve ser entendido como um banco de dados permanente de todos os sites utilizados pelo computador.
Como visualizar o cache DNS no Windows 11
Abra o Prompt de Comando ou Terminal do Windows.
Execute:
ipconfig /displaydns
O Windows exibirá o conteúdo disponível no cache do resolvedor DNS.
Dependendo do uso recente do computador, a saída pode ser bastante extensa.
Você poderá encontrar estruturas semelhantes a:
exemplo.com
seguidas por informações referentes ao registro.
O formato e os campos exibidos podem variar conforme o tipo de registro e a versão/localização do sistema.
O importante não é decorar a aparência.
Precisamos entender o significado das informações.
O que significa Record Name?
Um dos campos fundamentais identifica o nome relacionado ao registro DNS.
Podemos imaginar algo como:
Record Name . . . . . : exemplo.com
Esse é o nome ao qual a entrada armazenada se refere.
Mas existe uma armadilha importante:
encontrar um domínio no cache DNS não significa necessariamente que o usuário digitou aquele endereço no navegador.
Voltaremos a isso mais adiante.
O que significa Record Type?
DNS possui diferentes tipos de registros.
Em algumas saídas do Windows, o tipo pode aparecer representado numericamente.
Dois dos mais importantes para nosso objetivo são os registros usados para endereçamento IPv4 e IPv6.
Registro A
O registro A associa um nome a um endereço IPv4.
Exemplo conceitual:
servidor.exemplo.com
↓
192.0.2.20
Em uma consulta real, o endereço dependerá naturalmente do domínio e da infraestrutura utilizada.
Quando o Windows precisa encontrar o IPv4 correspondente a determinado nome, registros A podem participar da resolução.
Registro AAAA
O registro AAAA é utilizado para endereços IPv6.
Portanto, um mesmo nome pode possuir:
registro A → IPv4
e
registro AAAA → IPv6
Isso explica por que você pode encontrar informações IPv6 no cache mesmo sem ter digitado qualquer endereço IPv6 manualmente.
Aplicativos e o próprio sistema podem consultar registros AAAA automaticamente.
Em redes modernas com IPv4 e IPv6 funcionando simultaneamente, isso é perfeitamente normal.
Por que AAAA tem quatro letras A?
O registro A representa um endereço IPv4 de 32 bits.
O IPv6 utiliza endereços de 128 bits.
Como 128 é quatro vezes 32, historicamente o tipo recebeu o nome AAAA, ou “quad-A”.
Para o usuário, o mais importante é lembrar:
A = IPv4
AAAA = IPv6
Essa distinção será muito útil quando começarmos a interpretar problemas em redes dual stack.
O que é um registro CNAME?
CNAME significa:
Canonical Name
Ele permite que determinado nome funcione como um alias de outro nome.
Imagine:
download.exemplo.com
apontando logicamente para:
servidor.cdn.exemplo.net
O DNS pode então continuar a resolução até obter os dados necessários para alcançar o destino.
Essa estrutura é extremamente comum em infraestruturas modernas.
Sites utilizam:
- CDNs;
- serviços em nuvem;
- balanceadores;
- plataformas externas;
- múltiplos provedores.
Por isso, ao investigar DNS, nem sempre encontraremos uma relação simples:
nome digitado → um único IP
Pode existir uma cadeia de resolução.
Por que um único site gera tantos nomes no cache DNS?
Esse é um dos pontos mais interessantes do artigo.
Você abre apenas uma página.
Depois executa:
ipconfig /displaydns
e encontra diversos domínios.
Isso acontece porque uma página moderna raramente depende exclusivamente do domínio visível na barra de endereços.
Ela pode carregar recursos hospedados em outros serviços.
Por exemplo:
Página principal
↓
servidor do site
↓
CDN
↓
fontes
↓
imagens
↓
vídeos
↓
scripts
↓
serviços de autenticação
↓
APIs
↓
recursos de terceiros
Cada serviço pode utilizar nomes diferentes.
Além disso, aplicativos em segundo plano também realizam suas próprias resoluções DNS.
Portanto, o cache é compartilhado com atividades do sistema e de diferentes programas.
Domínio no cache DNS prova que alguém visitou aquele site?
Não.
Essa conclusão seria tecnicamente insegura.
Uma entrada DNS pode surgir porque:
- navegador solicitou determinado recurso;
- aplicativo realizou uma consulta;
- serviço do Windows acessou um servidor;
- página carregou conteúdo de terceiro;
- programa verificou atualizações;
- antivírus consultou infraestrutura externa;
- aplicação executou atividade em segundo plano.
Portanto:
entrada DNS ≠ prova de visita manual ao site.
O cache pode ser útil para diagnóstico.
Ele não deve ser tratado como histórico de navegação confiável.
O que é TTL?
Agora chegamos a uma das informações mais importantes.
TTL significa:
Time To Live
No contexto DNS, o TTL ajuda a determinar por quanto tempo uma informação pode permanecer válida em cache antes de precisar ser atualizada conforme as regras aplicáveis.
Imagine que uma resposta tenha TTL de:
300
Isso representa, conceitualmente:
300 segundos
ou:
5 minutos.
Enquanto o resultado armazenado continua válido, ele pode ser reutilizado.
À medida que o tempo passa, o período restante diminui.
Quando a entrada deixa de ser válida, uma nova resolução pode ser necessária.
TTL não significa latência
É fácil confundir as siglas e números.
TTL no DNS não indica:
- velocidade da Internet;
- Ping;
- latência;
- qualidade do Wi-Fi;
- distância até o servidor.
Ele está relacionado à validade temporal da informação armazenada.
Existe também um campo TTL no cabeçalho IP, com outra função relacionada ao percurso de pacotes.
Apesar de compartilharem o nome Time To Live, não devemos misturar os dois conceitos.
Esse é um detalhe importante principalmente para quem já utilizou o comando Ping e está acostumado a observar valores de TTL nas respostas.
O que acontece quando o TTL chega ao fim?
Quando uma entrada armazenada deixa de ser válida, o sistema não deve continuar tratando aquele resultado antigo como eternamente correto.
Se uma aplicação voltar a solicitar o nome, uma nova resolução poderá ocorrer.
Isso é essencial porque endereços e configurações DNS podem mudar.
Imagine:
Hoje:
servico.exemplo.com → IP A
Depois o administrador altera o DNS:
servico.exemplo.com → IP B
Caches existentes podem continuar utilizando temporariamente a informação anterior enquanto ela estiver válida.
É justamente por isso que alterações de DNS podem não parecer instantâneas em todos os clientes.
Então ipconfig /flushdns deixa a Internet mais rápida?
Não existe essa garantia.
Esse é um dos mitos mais comuns envolvendo comandos de rede no Windows.
O comando:
ipconfig /flushdns
limpa o cache do resolvedor DNS do Windows.
Ele pode ser útil quando existe uma informação armazenada que está causando um problema de resolução.
Mas isso não significa que limpar o cache periodicamente seja uma técnica universal para acelerar a Internet.
Na realidade, eliminar resultados válidos significa que determinadas resoluções precisarão ser realizadas novamente.
Portanto:
flushdns é uma ferramenta de diagnóstico e correção para situações específicas.
Não um “turbo de Internet”.
Quando limpar o cache DNS pode fazer sentido?
Imagine que determinado serviço mudou de endereço.
O DNS já foi atualizado.
Mas o computador continua tentando utilizar uma informação antiga ainda armazenada.
Nesse cenário, limpar o cache local pode ajudar a eliminar aquela variável.
Outro exemplo:
Você está investigando uma resolução incorreta e quer garantir que a próxima tentativa não reutilize determinado resultado armazenado anteriormente.
Execute:
ipconfig /flushdns
Depois faça novamente a consulta.
O comando passa a fazer parte de um experimento:
resultado com cache
versus
resultado após limpar o cache.
Isso é muito diferente de executá-lo aleatoriamente sempre que a Internet parece lenta.
Como confirmar que o cache foi limpo?
Execute:
ipconfig /flushdns
Depois:
ipconfig /displaydns
Não espere necessariamente encontrar uma tela eternamente vazia.
O Windows e os aplicativos podem começar a realizar novas resoluções rapidamente.
Dependendo da atividade do computador, novas entradas podem reaparecer quase imediatamente.
Isso é normal.
O cache está sendo reconstruído conforme novas consultas acontecem.
O serviço DNS Client do Windows
O Windows possui um componente de sistema relacionado à resolução e ao cache DNS, conhecido como DNS Client.
Em sistemas em português, você poderá encontrar referências ao serviço Cliente DNS.
Esse componente participa do mecanismo utilizado pelo Windows para resolução de nomes e armazenamento de resultados.
Isso ajuda a entender por que o cache não pertence exclusivamente ao navegador.
Ele faz parte da infraestrutura de rede do próprio sistema operacional.
Navegadores também podem possuir mecanismos próprios
Aqui o diagnóstico fica mais interessante.
Limpar o cache DNS do Windows não significa necessariamente limpar toda informação de resolução que possa existir em cada camada de uma aplicação.
Navegadores modernos possuem arquiteturas próprias e podem utilizar mecanismos adicionais relacionados a DNS e conexões.
Além disso, tecnologias como DNS over HTTPS (DoH) tornam o caminho da resolução ainda mais interessante.
Por isso, em determinados problemas, você pode executar:
ipconfig /flushdns
e perceber que o comportamento de uma aplicação não muda imediatamente.
Isso não significa necessariamente que o comando falhou.
Pode existir outra camada envolvida.
Cache DNS do Windows e cache do navegador não são exatamente a mesma coisa
Esse ponto merece ficar muito claro.
Podemos ter diferentes níveis envolvidos:
aplicação
↓
navegador
↓
mecanismos de resolução
↓
Windows
↓
servidor DNS
e, dependendo da configuração:
DoH / DNS seguro
pode alterar parte desse caminho.
Por isso, diagnosticar DNS exige descobrir:
quem está fazendo a resolução?
O Windows?
O navegador?
Uma VPN?
Um agente de segurança?
Outro software?
Essa pergunta será fundamental na próxima parte.
ipconfig /displaydns não mostra necessariamente toda a história
O comando é extremamente útil, mas não deve ser interpretado como uma janela universal para absolutamente todas as resoluções realizadas por todos os programas.
Ele mostra informações relacionadas ao cache do resolvedor DNS do Windows.
Se uma aplicação utiliza um mecanismo próprio ou outro caminho de resolução, o comportamento pode ser diferente.
Esse detalhe explica alguns casos aparentemente contraditórios:
Windows resolve um endereço de uma maneira
enquanto:
um navegador apresenta outro comportamento.
Quando isso acontece, precisamos comparar ferramentas.
nslookup, Resolve-DnsName e cache não são exatamente a mesma coisa
Outra armadilha comum é executar várias ferramentas e esperar que todas estejam fazendo exatamente o mesmo teste.
Não necessariamente.
Por exemplo, podemos utilizar:
nslookup exemplo.com
ou, no PowerShell:
Resolve-DnsName exemplo.com
Essas ferramentas ajudam a investigar DNS, mas precisam ser interpretadas de acordo com a maneira como realizam suas consultas e com o objetivo do teste.
Da mesma forma, ipconfig /displaydns possui outra função:
mostrar o cache do resolvedor DNS do Windows.
Um bom diagnóstico não pergunta apenas:
“Qual comando respondeu?”
Ele pergunta:
“Qual camada cada comando está testando?”
Um exemplo prático
Imagine:
Você tenta abrir:
portal.empresa.local
O programa não conecta.
Executa:
ipconfig /displaydns
e encontra uma entrada apontando para um endereço antigo.
Agora temos uma hipótese.
Podemos:
- registrar o endereço atual;
- limpar o cache;
- resolver novamente o nome;
- comparar o novo resultado;
- testar a aplicação.
Se depois da limpeza o nome passa a apontar para o endereço correto e o programa volta a funcionar, construímos uma relação muito mais convincente.
Observe que o diagnóstico não foi:
“Internet ruim → flushdns.”
Foi:
sintoma → cache → endereço antigo → limpeza controlada → nova resolução → teste.
Essa é a maneira mais útil de trabalhar com o cache DNS.
O cache DNS pode armazenar uma resposta de erro?
Sim — e aqui entramos em uma parte muito interessante.
Nem sempre o cache contém apenas respostas positivas.
Em determinadas situações, resultados negativos também podem ser armazenados temporariamente.
Isso é conhecido como:
negative caching
ou:
cache negativo.
Imagine que você tente acessar um nome que naquele momento não possa ser resolvido.
Pouco depois, o problema no DNS é corrigido.
Mesmo assim, determinados clientes podem continuar apresentando temporariamente o resultado anterior, dependendo do comportamento do cache e dos valores envolvidos.
Esse é um dos motivos pelos quais:
“Já corrigi o DNS, mas neste computador ainda não funciona.”
pode ser um problema legítimo de investigação.
Na próxima parte entraremos justamente nesse nível: cache positivo e negativo, TTL restante, registros A, AAAA e CNAME na prática, Resolve-DnsName, arquivo hosts, DoH, navegadores e como descobrir de qual camada está vindo uma resolução incorreta no Windows 11.
interpretando registros, TTL e cache negativo
Na primeira parte vimos que ipconfig /displaydns não deve ser tratado como simples lista de sites acessados. O comando mostra informações presentes no cache do resolvedor DNS do Windows, e essas entradas podem ter sido criadas por diferentes programas e componentes do sistema.
Agora podemos avançar para uma questão mais interessante:
como interpretar tecnicamente aquilo que aparece no cache?
Para isso, precisamos separar três conceitos:
nome consultado → tipo de registro → resposta obtida
e adicionar uma quarta variável:
por quanto tempo essa informação ainda pode ser utilizada?
É aí que entram TTL, registros positivos, respostas negativas e diferentes ferramentas de diagnóstico.
Começando novamente pelo ipconfig /displaydns
Abra o Terminal ou Prompt de Comando e execute:
ipconfig /displaydns
Dependendo do computador, você poderá receber dezenas ou centenas de entradas.
Em vez de tentar interpretar tudo, escolha um domínio específico.
Podemos também filtrar a saída utilizando ferramentas do próprio Windows.
No Prompt de Comando:
ipconfig /displaydns | findstr exemplo
No PowerShell, podemos utilizar:
ipconfig /displaydns | Select-String "exemplo"
Substitua exemplo por parte do nome que deseja investigar.
Isso facilita bastante quando o cache está grande.
O que significa cada campo do ipconfig /displaydns?
A apresentação pode variar conforme idioma e versão do Windows, mas uma entrada pode fornecer informações relacionadas a:
Record Name
Record Type
Time To Live
Data Length
Section
e o dado propriamente dito, como um endereço IP.
Vamos entender os campos mais importantes.
Record Name
É o nome associado àquela entrada DNS.
Exemplo conceitual:
www.exemplo.com
Não devemos confundir isso com o endereço IP.
O nome é aquilo sobre o qual existe uma informação armazenada.
Record Type
Indica o tipo do registro DNS.
Esse campo é fundamental porque DNS não trabalha apenas com endereços IPv4.
Alguns valores que podem aparecer durante uma investigação correspondem a tipos específicos de registro.
Entre os mais importantes:
1 = A
5 = CNAME
12 = PTR
28 = AAAA
Existem muitos outros tipos de registro DNS.
Não precisamos decorar todos.
Para diagnóstico cotidiano no Windows, compreender A, AAAA, CNAME e, em determinados cenários, PTR já ajuda bastante.
Registro A — endereço IPv4
Quando encontramos:
Record Type: 1
estamos diante de um registro A.
Ele está relacionado a um endereço IPv4.
Conceitualmente:
servidor.exemplo.com
↓
192.0.2.50
Se uma aplicação estiver tentando alcançar esse nome utilizando IPv4, esse resultado pode ser importante para determinar o destino da conexão.
Registro AAAA — endereço IPv6
Quando encontramos:
Record Type: 28
estamos diante de um registro AAAA.
Ele representa um endereço IPv6.
Um domínio pode possuir simultaneamente:
A → IPv4
AAAA → IPv6
Portanto, não devemos considerar a existência de dois endereços diferentes como um erro.
Em uma rede dual stack isso pode ser completamente normal.
Na realidade, um mesmo serviço pode possuir vários registros A e vários registros AAAA.
Um domínio pode ter vários endereços IP?
Sim.
Essa é outra interpretação incorreta comum.
Imagine executar uma consulta e receber:
203.0.113.10
203.0.113.11
203.0.113.12
Isso não significa necessariamente que o DNS esteja quebrado.
Serviços modernos podem distribuir tráfego entre diversos servidores.
CDNs e infraestruturas de alta disponibilidade também tornam essa situação comum.
Portanto:
um nome não precisa apontar obrigatoriamente para apenas um endereço IP.
CNAME — quando o nome aponta para outro nome
Agora imagine:
portal.exemplo.com
não possui diretamente o endereço final esperado.
Em vez disso, existe uma referência para outro nome:
portal.cdn.exemplo.net
Esse tipo de relacionamento pode envolver um registro CNAME.
O resolvedor então precisa continuar o processo para descobrir as informações necessárias sobre o nome de destino.
Podemos visualizar conceitualmente:
portal.exemplo.com
↓
CNAME
↓
portal.cdn.exemplo.net
↓
A / AAAA
↓
endereço de destino
Essa cadeia ajuda a explicar por que uma única consulta pode produzir várias informações relacionadas.
PTR — resolução no sentido contrário
Normalmente pensamos:
nome → endereço IP
Mas também existem consultas utilizadas para relacionar um endereço a um nome.
Registros PTR aparecem em mecanismos de resolução reversa.
Em vez de perguntar:
Qual é o IP de
servidor.exemplo.com?
a ideia passa a ser algo semelhante a:
Existe um nome associado a determinado endereço?
Esse tipo de consulta aparece em diferentes ferramentas administrativas e serviços de rede.
O que significa Data Length?
Esse campo representa o tamanho dos dados associados ao registro.
Ele não deve ser interpretado como:
- tamanho do site;
- quantidade de dados baixados;
- velocidade da conexão;
- tamanho do pacote de Internet.
É uma característica da informação do registro DNS.
Para diagnóstico básico, geralmente não é o campo mais importante.
O campo mais interessante: Time To Live
Suponha que você encontre:
Time To Live . . . . . : 240
Espere alguns segundos.
Execute novamente:
ipconfig /displaydns
O valor poderá estar menor.
Por exemplo:
227
Depois:
210
Esse comportamento ajuda a visualizar algo importante:
a entrada possui uma validade temporária.
Quando esse período termina, a informação armazenada deixa de ser utilizada como uma resposta válida daquela forma e uma nova resolução pode ser necessária.
Podemos observar o TTL diminuindo na prática
Faça um pequeno experimento.
Primeiro:
ipconfig /flushdns
Depois consulte um domínio que você tenha autorização e motivo para testar, utilizando normalmente um aplicativo ou uma ferramenta adequada.
Em seguida:
ipconfig /displaydns
Localize a entrada.
Anote o TTL.
Espere aproximadamente 30 segundos.
Execute novamente:
ipconfig /displaydns
Compare.
Em uma entrada apropriada para esse teste, você poderá observar a contagem restante diminuir.
Esse é um excelente exercício para entender que o cache DNS é dinâmico.
TTL alto é melhor?
Não existe uma resposta universal.
TTL maior permite que uma resposta permaneça em cache durante mais tempo.
Isso pode reduzir a necessidade de consultas repetidas.
Por outro lado, quando o administrador altera um registro, caches existentes podem continuar utilizando a informação anterior até que as condições de validade e atualização permitam buscar a nova resposta.
TTL menor permite alterações serem refletidas mais rapidamente nos clientes, mas também pode aumentar a frequência de consultas.
Por isso, administradores escolhem valores conforme as necessidades da infraestrutura.
O que é cache DNS positivo?
Imagine que o computador pergunte:
Qual é o endereço de
servidor.exemplo.com?
e receba uma resposta válida.
Essa informação pode ser armazenada temporariamente.
Podemos chamar isso, de maneira simplificada, de:
cache positivo.
A próxima solicitação poderá aproveitar a informação armazenada enquanto ela continuar válida.
E o que é cache DNS negativo?
Agora imagine outra situação.
Um programa tenta resolver:
servidor-inexistente.exemplo.com
e a resposta informa que aquele nome não existe.
Seria ineficiente repetir imediatamente a mesma consulta várias vezes.
Resultados negativos também podem ser armazenados temporariamente.
Esse mecanismo é chamado de:
negative caching
ou:
cache negativo.
Isso é extremamente importante em diagnóstico.
Um exemplo realista de cache negativo
Imagine uma empresa configurando um novo servidor:
erp.empresa.local
Às 10h00, um computador tenta resolver o nome.
O DNS ainda não possui a configuração correta.
A resolução falha.
Às 10h01, o administrador corrige o DNS.
Outro computador consegue acessar.
Mas o primeiro ainda apresenta problema temporariamente.
Uma das hipóteses a investigar é:
o cliente ainda possui informação negativa armazenada?
Nesse cenário, limpar o cache local pode ser um teste válido:
ipconfig /flushdns
Depois realizamos novamente a resolução.
Se o comportamento mudar, encontramos uma evidência importante.
Isso explica por que flushdns às vezes parece “consertar a Internet”
Sim, mas precisamos interpretar corretamente.
O comando não acelerou a conexão.
Ele eliminou informações presentes no cache do resolvedor.
Se alguma dessas informações estava relacionada ao problema, a próxima tentativa exigiu uma nova resolução e recebeu um resultado diferente.
Portanto:
flushdns pode resolver um problema DNS.
Isso é diferente de:
flushdns acelera a Internet.
Essa diferença parece pequena, mas tecnicamente é enorme.
Como testar antes e depois do flushdns
Em vez de executar comandos aleatoriamente, registre o estado.
Primeiro:
ipconfig /displaydns
Procure o nome problemático.
Depois execute uma consulta DNS apropriada.
No PowerShell:
Resolve-DnsName exemplo.com
Registre o resultado.
Agora, se houver motivo para testar a limpeza:
ipconfig /flushdns
Faça novamente a resolução.
Compare:
antes
versus
depois.
Isso transforma um comando de “tentativa e erro” em um procedimento de diagnóstico.
Resolve-DnsName: uma ferramenta poderosa do PowerShell
O PowerShell possui o cmdlet:
Resolve-DnsName
Um uso básico seria:
Resolve-DnsName exemplo.com
A saída pode mostrar diferentes informações, dependendo da resposta recebida.
Também podemos solicitar especificamente registros IPv4:
Resolve-DnsName exemplo.com -Type A
ou IPv6:
Resolve-DnsName exemplo.com -Type AAAA
Isso é muito útil para redes dual stack.
Testando IPv4 e IPv6 separadamente
Imagine que determinado serviço funciona via IPv4, mas existe suspeita de problema relacionado ao IPv6.
Podemos investigar os registros separadamente:
Resolve-DnsName exemplo.com -Type A
Depois:
Resolve-DnsName exemplo.com -Type AAAA
Agora temos respostas específicas para cada tipo.
Isso não prova sozinho que a conectividade IPv4 ou IPv6 esteja funcionando.
Lembre-se:
resolver um endereço não é o mesmo que conseguir estabelecer uma conexão com ele.
Mas já separamos uma etapa do diagnóstico.
Resolve-DnsName pode consultar um servidor DNS específico
Em determinados testes, podemos querer perguntar diretamente a um servidor DNS escolhido.
Por exemplo:
Resolve-DnsName exemplo.com -Server 1.1.1.1
ou outro servidor que você esteja autorizado a consultar.
Isso permite comparar respostas.
Por exemplo:
DNS configurado no computador
versus
outro resolvedor DNS
Se os resultados forem diferentes, temos uma nova pista.
Mas cuidado:
diferença não significa automaticamente erro.
CDNs, localização, políticas do resolvedor, tempo de atualização e outras características da infraestrutura podem produzir respostas distintas.
E onde entra o nslookup?
O nslookup continua sendo uma ferramenta muito conhecida.
Exemplo:
nslookup exemplo.com
Ele pode informar qual servidor foi utilizado e apresentar a resposta obtida.
Também podemos especificar um servidor:
nslookup exemplo.com 1.1.1.1
Isso é útil para comparação.
Mas existe um erro conceitual muito comum:
usar nslookup como se ele fosse simplesmente uma visualização do cache DNS do Windows.
Não é esse o papel da ferramenta.
Para visualizar o cache do resolvedor:
ipconfig /displaydns
Para realizar consultas e investigar respostas DNS:
nslookup
ou:
Resolve-DnsName
Cada ferramenta responde a uma pergunta diferente.
A pergunta correta muda completamente o comando
Em vez de decorar comandos, pense assim:
Quero saber o que está armazenado no cache do Windows.
Use:
ipconfig /displaydns
Quero limpar o cache do resolvedor.
Use:
ipconfig /flushdns
Quero consultar registros DNS de maneira detalhada pelo PowerShell.
Use:
Resolve-DnsName
Quero realizar uma consulta DNS usando uma ferramenta clássica.
Use:
nslookup
Esse raciocínio evita interpretações erradas.
O arquivo hosts entra antes do DNS?
Agora chegamos a outro componente importante:
C:\Windows\System32\drivers\etc\hosts
O arquivo hosts permite definir associações locais entre nomes e endereços.
Exemplo conceitual:
192.0.2.10 servidor.exemplo.local
Isso pode alterar a maneira como determinadas resoluções são tratadas pelo sistema.
Por isso, quando apenas um computador resolve um nome de forma inesperada, o arquivo hosts merece investigação.
Como abrir o arquivo hosts
O arquivo fica em:
C:\Windows\System32\drivers\etc\hosts
Você pode visualizá-lo com um editor de texto.
Para modificá-lo, normalmente são necessárias permissões administrativas.
Não saia apagando entradas sem saber por que estão ali.
Softwares corporativos, ferramentas de desenvolvimento e administradores podem utilizar o arquivo legitimamente.
O objetivo inicial deve ser:
inspecionar.
Quando o hosts vira uma pista importante?
Imagine:
Computador A:
portal.exemplo.com → endereço correto
Computador B:
portal.exemplo.com → endereço diferente
Ambos utilizam aparentemente o mesmo DNS.
Nesse caso, podemos investigar:
- cache DNS;
- arquivo hosts;
- configuração dos servidores DNS;
- VPN;
- proxy;
- software de segurança;
- mecanismos próprios da aplicação.
A investigação começa a ficar muito mais interessante.
E o navegador?
Agora encontramos uma das maiores fontes de confusão.
Você executa:
ipconfig /flushdns
Depois:
Resolve-DnsName
O resultado parece correto.
Mas o navegador continua apresentando um comportamento diferente.
Nesse momento, não devemos concluir imediatamente:
“O Windows está ignorando o DNS.”
O navegador pode possuir mecanismos próprios relacionados a resolução, cache, conexões persistentes e DNS seguro.
DNS over HTTPS muda o diagnóstico
DNS over HTTPS, ou DoH, permite transportar consultas DNS utilizando HTTPS.
Dependendo da configuração do sistema e da aplicação, isso pode alterar qual resolvedor efetivamente participa de determinada consulta.
Imagine:
Windows configurado para usar:
Servidor DNS A
mas um navegador configurado para utilizar DNS seguro por meio de:
Servidor DNS B
Agora temos dois caminhos potencialmente diferentes.
Por isso:
nslookup
pode mostrar uma resposta,
enquanto determinada aplicação pode apresentar outro comportamento.
Isso não significa necessariamente que uma das ferramentas esteja “mentindo”.
Elas podem não estar testando exatamente o mesmo caminho.
VPN também pode mudar completamente a resolução DNS
Ao conectar uma VPN, ela pode:
- fornecer servidores DNS próprios;
- criar novas interfaces;
- adicionar rotas;
- definir sufixos DNS;
- aplicar políticas;
- resolver nomes internos da organização.
Por isso, um problema que aparece somente com VPN conectada deve ser investigado nesse contexto.
Teste:
VPN desconectada
versus
VPN conectada
e compare as configurações.
Como descobrir quais servidores DNS estão configurados no Windows 11
No PowerShell:
Get-DnsClientServerAddress
A saída mostra os servidores associados às interfaces.
Como o computador pode possuir várias interfaces, você poderá encontrar informações para:
- Ethernet;
- Wi-Fi;
- VPN;
- adaptadores virtuais;
- interfaces adicionais.
Isso é importante porque perguntar apenas:
“Qual é o DNS do computador?”
pode ser simplificar demais.
O Windows pode possuir múltiplas interfaces e configurações.
Filtrando informações IPv4
Podemos executar:
Get-DnsClientServerAddress -AddressFamily IPv4
Para IPv6:
Get-DnsClientServerAddress -AddressFamily IPv6
Agora conseguimos observar as configurações separadamente.
Descobrindo a configuração de uma interface específica
Outro comando útil:
Get-DnsClient
Ele mostra informações relacionadas às interfaces e ao cliente DNS.
Em ambientes com Ethernet, Wi-Fi, VPN e adaptadores virtuais, essa visão pode ajudar bastante.
O sufixo DNS também importa
Em redes corporativas, nomes podem ser consultados de maneira diferente dependendo dos sufixos configurados.
Imagine que o usuário digite apenas:
servidor01
O sistema pode utilizar informações de sufixo para tentar formar um nome mais completo.
Por exemplo:
servidor01.empresa.local
Esse comportamento é especialmente relevante em:
- Active Directory;
- VPN;
- redes empresariais;
- ambientes com domínios internos.
Portanto, “DNS funciona para sites, mas não encontra o servidor da empresa” não significa necessariamente que o DNS inteiro esteja quebrado.
Pode existir um problema específico de:
zona interna
ou:
sufixo DNS
ou:
servidor DNS utilizado naquela interface.
Uma metodologia melhor para diagnosticar DNS
Quando um nome não resolve corretamente no Windows 11, siga uma sequência lógica.
Primeiro:
Qual nome apresenta problema?
Depois:
Qual resposta o Windows está utilizando?
Verifique o cache:
ipconfig /displaydns
Depois consulte:
Resolve-DnsName nome
Compare com:
nslookup nome
Verifique os servidores configurados:
Get-DnsClientServerAddress
Inspecione:
hosts
Se houver VPN, teste com e sem ela quando isso for apropriado.
Se apenas o navegador apresenta problema, investigue:
DNS seguro, cache e configurações do próprio navegador.
Agora estamos separando camadas.
Não troque o DNS antes de entender o problema
Outro hábito comum é trocar imediatamente o DNS para:
Google,
Cloudflare,
Quad9
ou outro serviço.
Isso pode até mudar o comportamento em determinadas situações.
Mas trocar o DNS antes de registrar o problema pode destruir uma pista importante.
Primeiro descubra:
qual servidor estava sendo utilizado?
qual resposta ele fornecia?
a resposta era diferente em outro servidor?
Depois faça a alteração, se houver motivo.
Em diagnóstico técnico:
registrar → comparar → alterar → testar
é muito melhor que:
alterar tudo → verificar se funcionou.
O cache DNS pode revelar muito, mas precisa ser interpretado corretamente
Depois dessas duas partes, já conseguimos olhar para:
ipconfig /displaydns
de maneira completamente diferente.
Não vemos mais apenas uma lista enorme de nomes.
Vemos:
registros
tipos
endereços
TTL
respostas positivas
respostas negativas
IPv4
IPv6
aliases
informações temporárias
e, principalmente:
pistas de diagnóstico.
Mas ainda falta responder uma pergunta importante:
Como usar tudo isso quando um computador apresenta um problema real?
Na próxima parte vamos montar cenários completos de diagnóstico:
site abre em um computador e não abre em outro;
DNS continua apontando para IP antigo;
nslookup funciona, mas o navegador não;
nome interno funciona conectado à VPN e falha fora dela;
IPv4 funciona, mas IPv6 apresenta comportamento diferente;
flushdns resolve temporariamente, mas o problema volta.
A partir desses casos, poderemos identificar não apenas o que existe dentro do cache DNS do Windows 11, mas também quando ele é realmente o culpado — e quando estamos investigando a camada errada.
diagnóstico de problemas reais de DNS
Conhecer os registros existentes no cache DNS é útil, mas o verdadeiro valor desse conhecimento aparece quando alguma coisa para de funcionar.
Um site não abre.
Um servidor interno não é encontrado.
Um computador acessa determinado endereço enquanto outro não consegue.
O administrador altera o IP de um servidor, mas algumas máquinas continuam tentando acessar o endereço antigo.
nslookup responde corretamente, porém o navegador continua apresentando erro.
Nessas situações, executar ipconfig /flushdns pode fazer parte do diagnóstico, mas não deveria ser automaticamente o primeiro e único procedimento.
O objetivo desta parte é descobrir em qual camada o problema realmente está acontecendo.
Caso 1 — um site funciona em outro computador, mas não neste
Imagine dois computadores conectados à mesma rede.
No primeiro:
www.exemplo.com
abre normalmente.
No segundo:
o navegador apresenta erro.
Isso imediatamente cria uma informação importante.
Se ambos realmente utilizam a mesma conexão e o serviço está disponível no primeiro computador, uma indisponibilidade geral da Internet se torna menos provável.
Precisamos investigar o segundo computador.
Comece verificando a resolução:
Resolve-DnsName exemplo.com
Observe os endereços retornados.
Depois, no outro computador, faça a mesma consulta.
Se os resultados forem compatíveis, o problema pode estar depois da resolução DNS.
Se forem diferentes, temos uma pista.
Verifique o cache antes de apagá-lo
Esse detalhe é fundamental.
Antes de executar:
ipconfig /flushdns
execute:
ipconfig /displaydns
Procure pelo domínio problemático.
Você pode utilizar:
ipconfig /displaydns | findstr exemplo
ou no PowerShell:
ipconfig /displaydns | Select-String "exemplo"
Por quê?
Porque limpar o cache imediatamente destrói justamente uma das informações que poderiam ajudar no diagnóstico.
Primeiro:
observe.
Depois:
registre.
Só então:
altere.
Caso 2 — o servidor mudou de IP, mas o computador continua tentando acessar o antigo
Esse é um cenário clássico.
Imagine que:
servidor.empresa.local
anteriormente apontava para:
192.168.1.20
Agora deveria apontar para:
192.168.1.30
Em determinado computador, porém, a aplicação continua tentando alcançar:
192.168.1.20
Primeiro verifique:
ipconfig /displaydns
Procure o nome.
Depois:
Resolve-DnsName servidor.empresa.local
Agora temos algumas possibilidades.
O cache pode possuir uma informação antiga ainda válida.
O servidor DNS consultado pelo computador pode ainda fornecer o endereço antigo.
O arquivo hosts pode conter uma associação manual.
Uma VPN pode estar fornecendo outro DNS.
Ou a própria aplicação pode possuir alguma configuração ou cache independente.
Por isso, simplesmente executar flushdns não identifica automaticamente a causa.
Descubra quem está fornecendo o endereço antigo
Podemos perguntar diretamente ao DNS configurado.
Primeiro veja as configurações:
Get-DnsClientServerAddress
Depois faça a consulta.
Por exemplo:
Resolve-DnsName servidor.empresa.local
Se necessário, compare consultando diretamente um servidor específico autorizado:
Resolve-DnsName servidor.empresa.local -Server ENDERECO_DO_DNS
Agora a pergunta fica mais precisa:
o servidor DNS está respondendo com o endereço antigo ou apenas o cliente está reutilizando uma informação armazenada?
Essa distinção muda completamente a solução.
Cache antigo e DNS errado são problemas diferentes
Considere dois cenários.
Cenário A
Servidor DNS responde:
192.168.1.30
mas o computador ainda possuía temporariamente:
192.168.1.20
Nesse caso, o cache local merece atenção.
Cenário B
O próprio servidor DNS responde:
192.168.1.20
Agora limpar o cache repetidamente não resolve a origem do problema.
A próxima consulta simplesmente poderá receber novamente a informação incorreta.
A investigação precisa avançar para:
servidor DNS
zona DNS
registro
replicação
ou outra camada da infraestrutura.
Essa é a diferença entre corrigir o sintoma e encontrar a origem.
Caso 3 — nslookup funciona, mas o navegador não abre o site
Esse cenário confunde bastante.
Você executa:
nslookup exemplo.com
e recebe uma resposta.
Então conclui:
O DNS está funcionando, portanto o navegador deveria abrir.
Não necessariamente.
O nslookup responder corretamente demonstra algo sobre a consulta realizada por aquela ferramenta.
Ainda existem outras etapas para carregar um site.
Uma sequência extremamente simplificada seria:
resolver o nome
↓
escolher endereço
↓
estabelecer conectividade
↓
estabelecer conexão TCP ou outro transporte aplicável
↓
TLS/HTTPS quando utilizado
↓
HTTP
↓
aplicação
Portanto:
DNS resolvido ≠ site funcionando.
Teste a porta do serviço
Suponha que o site utilize HTTPS.
Podemos investigar conectividade TCP com:
Test-NetConnection exemplo.com -Port 443
Observe especialmente:
TcpTestSucceeded
Se a resolução ocorre, mas a conexão TCP não é estabelecida, precisamos olhar além do cache DNS.
Podemos estar diante de:
- firewall;
- proxy;
- rota;
- bloqueio;
- servidor indisponível;
- problema de conectividade;
- configuração de segurança;
- outra falha de rede.
O cache DNS deixa de ser o principal suspeito.
Caso 4 — navegador não abre, mas outras aplicações funcionam
Agora imagine:
Resolve-DnsName funciona.
Test-NetConnection para a porta apropriada funciona.
Outros programas acessam a Internet.
Mas determinado navegador continua falhando.
A investigação deve começar a se aproximar da aplicação.
Verifique, conforme o navegador utilizado:
- DNS seguro/DoH;
- proxy;
- extensões;
- políticas;
- cache;
- software de segurança;
- configurações específicas do navegador.
Esse é um princípio importante:
quando o problema existe em apenas uma aplicação, investigue também aquilo que é exclusivo daquela aplicação.
Caso 5 — flushdns resolve, mas o problema volta
Esse é um cenário particularmente interessante.
O usuário executa:
ipconfig /flushdns
Tudo funciona.
Algum tempo depois:
o problema retorna.
Executa novamente:
ipconfig /flushdns
Funciona outra vez.
É tentador concluir:
O cache DNS do Windows está com defeito.
Mas precisamos perguntar:
por que uma informação problemática está voltando ao cache?
Se a origem continua fornecendo a mesma resposta, o cache pode estar apenas armazenando aquilo que recebeu.
Precisamos investigar:
qual nome?
qual endereço problemático?
qual DNS forneceu essa resposta?
quanto tempo depois ela reaparece?
a VPN estava conectada?
acontece em Ethernet e Wi-Fi?
outros computadores recebem a mesma resposta?
Agora estamos procurando a origem.
O cache pode ser o mensageiro, não o culpado
Esse conceito vale guardar.
Encontrar uma informação errada no cache não prova que o mecanismo de cache criou o erro.
O Windows pode simplesmente ter armazenado uma resposta obtida anteriormente.
É semelhante a encontrar um endereço errado anotado em um papel.
O papel preservou a informação.
Mas precisamos descobrir:
quem forneceu o endereço errado?
No DNS, essa pergunta é essencial.
Caso 6 — funciona fora da VPN, mas falha quando conecta
VPNs frequentemente alteram elementos importantes da rede.
Elas podem fornecer:
- servidores DNS;
- rotas;
- sufixos DNS;
- interfaces virtuais;
- políticas;
- acesso a zonas internas.
Faça uma comparação.
Antes de conectar a VPN:
Get-DnsClientServerAddress
Depois conecte a VPN e execute novamente:
Get-DnsClientServerAddress
Observe as interfaces.
Agora faça:
Resolve-DnsName exemplo.com
Compare o comportamento.
Se o problema surge somente com a VPN conectada, temos uma fronteira de diagnóstico muito valiosa.
Split DNS: o mesmo nome pode ter respostas diferentes
Em ambientes empresariais, um mesmo nome pode ter comportamento diferente dependendo de onde a consulta ocorre.
Isso pode fazer parte de uma arquitetura planejada.
Por exemplo, usuários internos podem receber uma resposta apropriada à rede corporativa, enquanto consultas externas recebem outra.
VPNs também podem fornecer acesso a zonas DNS que não existem publicamente.
Por isso:
respostas diferentes não significam automaticamente servidor DNS defeituoso.
Precisamos conhecer o contexto da rede.
Caso 7 — nome curto funciona em um computador e não em outro
Imagine acessar:
servidor01
Em um computador funciona.
Em outro não.
Mas:
servidor01.empresa.local
funciona nos dois.
Isso sugere investigar:
sufixos DNS.
No PowerShell:
Get-DnsClient
Também podemos analisar a configuração das interfaces e do ambiente.
Em redes corporativas, resolver nomes curtos pode depender de configurações adicionais.
Portanto, dizer simplesmente:
O DNS está quebrado.
seria impreciso.
A resolução do nome completo pode estar perfeita.
O problema pode estar na maneira como o nome curto é expandido ou pesquisado.
Caso 8 — IPv4 funciona e IPv6 apresenta problema
Um domínio pode possuir:
A
e:
AAAA
Faça consultas separadas:
Resolve-DnsName exemplo.com -Type A
Depois:
Resolve-DnsName exemplo.com -Type AAAA
Agora sabemos quais endereços foram publicados.
Mas novamente:
DNS não testa a conectividade até eles.
Se existir suspeita de problema IPv6, precisamos analisar a conectividade IPv6 propriamente dita, além da resolução.
Não é recomendável simplesmente desativar IPv6 em todos os computadores como solução genérica.
Primeiro determine se o problema realmente está relacionado a ele.
Caso 9 — alterar o DNS “resolveu”
Imagine trocar o DNS configurado no computador.
Antes:
DNS A.
Depois:
DNS B.
O problema desaparece.
Isso é uma pista importante.
Mas ainda não responde completamente:
por que o DNS A apresentava comportamento diferente?
Pode existir:
- registro desatualizado;
- problema de resolução;
- filtragem;
- política;
- diferença de cache;
- diferença de infraestrutura;
- resposta baseada em localização;
- configuração específica.
Se o objetivo é apenas restabelecer rapidamente um ambiente doméstico, uma mudança controlada pode ser suficiente.
Mas em diagnóstico técnico, vale entender o motivo.
Como consultar diferentes servidores DNS sem mudar a configuração do Windows
Essa é uma técnica muito útil.
Não precisamos alterar imediatamente o DNS da placa de rede.
Podemos comparar consultas diretamente.
Exemplo:
Resolve-DnsName exemplo.com -Server 1.1.1.1
Depois:
Resolve-DnsName exemplo.com -Server 8.8.8.8
E podemos comparar com o DNS normalmente utilizado pelo computador.
Isso preserva a configuração original enquanto coletamos evidências.
Em redes corporativas, naturalmente, servidores públicos podem não conhecer nomes internos.
Portanto, escolha os testes de acordo com o ambiente.
Caso 10 — arquivo hosts está alterando a resolução
Se apenas um computador insiste em utilizar um endereço diferente, inspecione:
C:\Windows\System32\drivers\etc\hosts
Procure pelo domínio envolvido.
Uma associação manual pode explicar por que aquele computador se comporta de maneira diferente.
Mas cuidado:
não apague tudo automaticamente.
Primeiro determine:
quem criou a entrada?
ela ainda é necessária?
faz parte de alguma aplicação?
foi criada pelo administrador?
Diagnóstico vem antes da alteração.
Um problema de DNS pode ser um problema de DHCP
Isso acontece principalmente quando o computador recebe automaticamente sua configuração de rede.
O DHCP pode fornecer não apenas:
endereço IP
máscara
gateway
mas também:
servidores DNS.
Portanto, se vários dispositivos começam a utilizar um DNS inesperado, vale descobrir de onde essa configuração está vindo.
No Windows:
ipconfig /all
Procure a interface ativa e observe:
Servidores DNS
Isso pode revelar que o computador está usando um resolvedor diferente daquele imaginado.
Não confunda gateway com DNS
Em muitas redes domésticas, o endereço do roteador aparece como servidor DNS.
Por exemplo:
192.168.1.1
Isso pode ser perfeitamente normal.
O roteador pode atuar como intermediário/encaminhador para consultas DNS.
Em outras configurações, o computador pode receber diretamente endereços de servidores DNS externos.
Portanto:
DNS não precisa obrigatoriamente ter o mesmo endereço do gateway.
E:
gateway e servidor DNS exercem funções diferentes.
Como descobrir rapidamente qual DNS está sendo usado
No PowerShell:
Get-DnsClientServerAddress
Para reduzir a saída:
Get-DnsClientServerAddress -AddressFamily IPv4
Outra opção:
ipconfig /all
O importante é identificar a interface realmente relevante.
Computadores modernos podem possuir:
Ethernet,
Wi-Fi,
Bluetooth,
VPN,
Hyper-V,
WSL,
adaptadores virtuais,
software de virtualização.
Olhar uma interface desconectada e concluir que aquele é o DNS ativo pode levar o diagnóstico para o caminho errado.
Caso 11 — o problema acontece somente no Wi-Fi
Se Ethernet funciona e Wi-Fi não, compare as configurações.
Execute:
Get-DnsClientServerAddress
Observe os servidores associados a cada interface.
Pode existir diferença entre elas.
Agora temos uma pergunta objetiva:
Wi-Fi e Ethernet estão usando os mesmos servidores DNS?
Se não, essa diferença merece investigação.
Se sim, precisamos procurar outra variável.
Caso 12 — DNS está correto, mas o programa continua tentando o IP antigo
Esse cenário é muito importante.
Você verifica:
Resolve-DnsName servidor.exemplo.com
Resultado:
IP novo.
Verifica o DNS.
IP novo.
Limpa:
ipconfig /flushdns
Mesmo assim a aplicação tenta acessar:
IP antigo.
Agora o cache DNS do Windows perde força como hipótese.
Talvez a aplicação:
- tenha armazenado o endereço;
- possua configuração própria;
- utilize arquivo de configuração;
- mantenha conexão existente;
- utilize proxy;
- consulte outro mecanismo;
- tenha sido configurada diretamente com IP.
Essa mudança de hipótese evita perder horas tentando “consertar o DNS” quando o DNS já está correto.
Como descobrir se o problema é realmente DNS
Podemos resumir o raciocínio em uma sequência.
Etapa 1 — identifique o nome
Qual endereço apresenta problema?
Não aceite apenas:
“a Internet não abre.”
Descubra o nome específico.
Etapa 2 — observe o cache
ipconfig /displaydns
Existe uma entrada relacionada?
Qual endereço?
Qual TTL?
Etapa 3 — faça uma consulta
Resolve-DnsName exemplo.com
Qual resposta foi obtida?
Etapa 4 — identifique os servidores DNS
Get-DnsClientServerAddress
Qual interface?
Quais servidores?
Etapa 5 — compare
Outro computador apresenta a mesma resposta?
Outro servidor DNS responde da mesma forma?
Etapa 6 — teste a conectividade
Se o nome resolve corretamente, o serviço realmente responde?
Por exemplo:
Test-NetConnection exemplo.com -Port 443
Etapa 7 — investigue a aplicação
Se apenas um navegador ou programa falha, procure elementos específicos dele.
Uma tabela mental para diagnóstico
| Situação | Primeira hipótese a investigar |
|---|---|
| Nome não resolve | DNS/resolução |
| IP antigo aparece no cache | validade/origem da resposta |
| DNS responde IP antigo | servidor/zona DNS |
Resolve-DnsName correto, navegador falha | aplicação/DoH/proxy/conectividade |
| Só falha com VPN | DNS/rota/política da VPN |
| Nome completo funciona, nome curto não | sufixo DNS |
| Só um computador resolve errado | cache/hosts/configuração local |
| Todos resolvem errado | infraestrutura DNS |
| Nome resolve, porta não conecta | problema além do DNS |
flushdns resolve e depois volta | investigar quem está recriando a resposta problemática |
Essa tabela não substitui diagnóstico.
Ela serve para indicar a próxima pergunta.
O perigo do “kit de comandos para consertar Internet”
Na Internet encontramos frequentemente sequências como:
ipconfig /flushdns
ipconfig /release
ipconfig /renew
netsh winsock reset
seguidas por reinicialização.
Esses comandos atuam em componentes diferentes.
Executá-los todos de uma vez pode eventualmente alterar o comportamento, mas reduz nossa capacidade de descobrir qual componente estava relacionado ao problema.
Em suporte técnico, prefira:
um teste por vez.
Registre:
antes
↓
alteração
↓
depois.
Essa metodologia produz conhecimento reutilizável.
ipconfig /flushdns e ipconfig /renew fazem coisas diferentes
Isso merece destaque.
ipconfig /flushdns
está relacionado ao cache do resolvedor DNS.
Já:
ipconfig /renew
está relacionado à renovação da configuração obtida via DHCP nas interfaces aplicáveis.
Um não é substituto do outro.
Se o problema é uma entrada DNS armazenada, renovar DHCP pode não ser necessário.
Se o computador recebeu servidores DNS incorretos via DHCP, apenas limpar o cache também não corrige a origem dessa configuração.
Mais uma vez:
entenda a camada antes de escolher o comando.
netsh winsock reset também não é um “flushdns mais forte”
Outro equívoco comum.
Winsock faz parte da infraestrutura utilizada pelas aplicações para comunicação de rede no Windows.
Redefinir componentes relacionados ao Winsock é uma ação diferente de limpar o cache DNS.
Não devemos escalar automaticamente:
flushdns
↓
renew
↓
winsock reset
↓
“reset de rede”
como se fossem níveis progressivamente mais fortes da mesma ferramenta.
Eles atuam em áreas diferentes.
Quando o cache DNS realmente merece ser o principal suspeito?
A suspeita fica mais interessante quando conseguimos demonstrar algo como:
- existe uma entrada armazenada relacionada ao problema;
- essa informação difere da resposta que deveria ser utilizada;
- a origem atual fornece uma resposta correta;
- após eliminar a entrada armazenada, uma nova resolução recebe a informação correta;
- o problema desaparece.
Agora existe uma cadeia lógica.
Muito diferente de simplesmente afirmar:
Limpei o DNS e voltou.
Diagnóstico DNS: descubra onde a resposta muda
Uma excelente maneira de pensar é visualizar camadas:
Aplicação
↓
mecanismo de resolução utilizado pela aplicação
↓
resolvedor do Windows
↓
cache
↓
configuração da interface
↓
servidor DNS
↓
infraestrutura DNS
Quando dois testes apresentam resultados diferentes, pergunte:
Em qual ponto os caminhos deixaram de ser iguais?
Essa pergunta frequentemente leva à causa.
O cache DNS é uma ferramenta de diagnóstico, não apenas algo para limpar
Talvez essa seja a principal mensagem deste artigo.
Durante anos, muitos tutoriais ensinaram:
Problema de Internet? Execute ipconfig /flushdns.
Mas existe uma abordagem muito mais útil.
Antes de limpar:
ipconfig /displaydns
Observe.
Interprete.
Procure:
- nome;
- tipo;
- endereço;
- TTL;
- comportamento inesperado.
Depois compare com:
Resolve-DnsName
nslookup
Get-DnsClientServerAddress
e, quando necessário:
Test-NetConnection
Agora o cache deixa de ser apenas algo que apagamos.
Ele vira uma fonte de evidências sobre o processo de resolução de nomes do Windows 11.
Checklist VMIA para investigar problemas de DNS no Windows 11
Antes de alterar configurações, responda:
1. Qual nome apresenta problema?
2. O problema ocorre em todos os programas ou apenas em um?
3. Outros computadores apresentam o mesmo comportamento?
4. O nome aparece em ipconfig /displaydns?
5. Qual endereço está armazenado?
6. Qual é o TTL restante?
7. Resolve-DnsName retorna qual resultado?
8. Qual servidor DNS a interface está utilizando?
9. Existe VPN ativa?
10. O arquivo hosts possui alguma entrada relacionada?
11. IPv4 e IPv6 apresentam respostas diferentes?
12. O nome resolve, mas o serviço continua inacessível?
13. O problema desaparece depois de limpar o cache?
14. Se desaparece, ele retorna depois?
15. Quem está fornecendo novamente a informação problemática?
Responder essas perguntas costuma ser muito mais produtivo do que executar uma longa sequência de comandos sem saber o que cada um está testando.
Conclusão: o que realmente existe dentro do cache DNS do Windows 11?
Quando executamos:
ipconfig /displaydns
não estamos vendo simplesmente uma lista de sites visitados.
Estamos observando informações temporárias utilizadas pelo mecanismo de resolução DNS do Windows.
Podemos encontrar registros relacionados a:
IPv4
IPv6
aliases
resoluções realizadas por aplicações
serviços do Windows
recursos externos
resultados temporariamente armazenados
e até situações envolvendo cache negativo.
Também encontramos uma das informações mais importantes:
TTL.
Ele ajuda a compreender por quanto tempo determinadas informações permanecem válidas no cache.
O mais importante, entretanto, é mudar a maneira de utilizar a ferramenta.
Em vez de começar sempre com:
ipconfig /flushdns
comece com:
ipconfig /displaydns
Primeiro veja o que existe.
Depois formule uma hipótese.
Compare a resposta com outras ferramentas.
Identifique o servidor DNS.
Teste a conectividade.
Só então altere alguma coisa.
Essa é a diferença entre simplesmente tentar comandos e realmente diagnosticar uma rede.
FAQ — Cache DNS no Windows 11
O que é o cache DNS do Windows 11?
É um mecanismo que permite ao resolvedor DNS do Windows manter temporariamente determinadas informações de resolução, evitando a necessidade de repetir imediatamente algumas consultas.
Como visualizar o cache DNS?
Abra o Prompt de Comando ou Terminal e execute:
ipconfig /displaydns
Como limpar o cache DNS?
Execute:
ipconfig /flushdns
Em situações que exigem elevação, abra o terminal com os privilégios apropriados.
Limpar o cache DNS aumenta a velocidade da Internet?
Não como regra geral.
O comando remove informações armazenadas no cache do resolvedor. Ele pode ajudar quando uma dessas informações participa de um problema, mas não funciona como acelerador universal de Internet.
O que significa TTL no cache DNS?
TTL significa Time To Live e está relacionado ao período durante o qual uma informação DNS pode permanecer válida em cache conforme as regras aplicáveis.
O TTL do DNS é o mesmo TTL mostrado pelo Ping?
Não.
Apesar do mesmo nome, são utilizados em contextos diferentes.
O que significa registro A?
É um tipo de registro DNS utilizado para associar um nome a um endereço IPv4.
O que significa AAAA?
É o tipo utilizado para endereços IPv6.
O que é CNAME?
É um registro utilizado para criar um nome canônico/alias, permitindo que um nome se refira a outro nome.
O que é cache DNS negativo?
É o armazenamento temporário de determinados resultados negativos de resolução, evitando repetir imediatamente consultas que acabaram de retornar esse tipo de resultado.
Um domínio presente em displaydns significa que alguém visitou o site?
Não.
Aplicativos, serviços, páginas carregando recursos externos e processos em segundo plano também podem provocar resoluções DNS.
nslookup mostra o cache DNS do Windows?
Não deve ser utilizado com essa interpretação.
Para visualizar o cache do resolvedor DNS do Windows, utilize ipconfig /displaydns.
Qual a diferença entre nslookup e Resolve-DnsName?
Ambos podem ser utilizados para investigar consultas DNS, mas possuem interfaces e recursos diferentes. Resolve-DnsName integra-se ao PowerShell e oferece opções úteis para consultas e automação.
Por que nslookup funciona, mas o navegador não?
Porque resolver o nome é apenas uma etapa. O problema pode estar na conectividade, porta, TLS, proxy, DoH, navegador, firewall ou em outra camada.
Por que flushdns resolve o problema apenas temporariamente?
Uma possibilidade é que uma informação problemática esteja sendo armazenada novamente. Nesse caso, é necessário descobrir de onde ela está vindo em vez de limpar o cache repetidamente.
VMIA — diagnóstico de problemas de Internet, Windows e redes
Problemas de DNS podem parecer simples, mas muitas vezes envolvem diferentes camadas do Windows, roteador, DHCP, VPN, navegador e infraestrutura de rede.
A VMIA trabalha com diagnóstico de computadores Windows, redes domésticas, Wi-Fi, roteadores, impressoras e problemas de conectividade, buscando identificar a causa do problema antes de alterar configurações indiscriminadamente.
VMIA – Manutenção e Configuração
Atendimento com agendamento.
Telefone/WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Dependendo do problema, o diagnóstico pode ser realizado por acesso remoto. Casos envolvendo infraestrutura física, roteadores, cabeamento, Wi-Fi ou equipamentos também podem exigir atendimento presencial.
VMIA: primeiro descubra em qual camada está o problema. Depois escolha a ferramenta certa para resolvê-lo.
Faça um comentário