dig e nslookup: como diagnosticar um domínio que não resolve

Publicado em 2026-10-26 por frfrand

Consultar servidores DNS, registros e cache pelo terminal

dig e nslookup: como diagnosticar um domínio que não resolve

api.ejemplo.com abre no telefone, mas não no seu computador. Antes de excluir configurações DNS aleatoriamente, pergunte diretamente aos resolvers qual resposta eles estão entregando. dig e nslookup servem para isso.

Vamos transformá-lo em um procedimento que você pode usar em um VPS real. O objetivo é entender por que funciona, como testá-lo e qual problema aparece se uma parte estiver mal configurada.

O que significa dig vs nslookup e quando você precisa

Ambas as ferramentas fazem consultas DNS. dig costuma facilitar a análise de TTL, respostas e servidores; nslookup está disponível em muitas instalações Windows. Escolher uma depende do sistema e das informações que você precisa ver.

Antes de alterar qualquer coisa em produção, anote o estado atual: IP, domínio, porta, serviço afetado e hora do último deploy. Uma modificação isolada é fácil de verificar; cinco mudanças simultâneas tornam mais difícil reconstruir o que aconteceu.

Configuração ou comandos de exemplo

dig api.ejemplo.com A +noall +answer
dig @1.1.1.1 api.ejemplo.com A
nslookup api.ejemplo.com
nslookup api.ejemplo.com 8.8.8.8
# NS del dominio
dig ejemplo.com NS +short

Os domínios, IPs, caminhos e nomes são ilustrativos. Não copie uma configuração inteira sobre a atual sem comparar primeiro. Nos exemplos que incluem portas ou firewall, certifique-se de manter o acesso administrativo.

Como eu faria passo a passo

Preparação. Consulte a resolução normal do seu sistema e anote o endereço recebido.
Passo 2. Pergunte a um resolvedor público diferente para detectar discrepâncias.
Passo 3. Revise o TTL e os servidores autoritativos do domínio.
Passo 4. Se o IP estiver correto, prossiga para testar TCP 443 e HTTPS; DNS não é toda a conexão.
Verificação. Se você alterou o domínio, verifique se não existe um AAAA antigo ou um CNAME para outro destino.

Quando terminar, comprove a operação real a partir de outra conexão. Por exemplo, para uma API não basta abrir o navegador: execute uma solicitação de leitura, uma gravação em um banco de teste e consulte os logs do processo.

Exemplo de um projeto de verdade

Você migrou um site WordPress para um VPS novo e um navegador ainda vê a versão anterior. dig mostra IP antigo em um resolvedor, mas o autoritativo já responde o novo. Isso sugere cache, não que o Nginx esteja mal configurado.

A lição é simples: uma configuração de infraestrutura não vive isolada da aplicação. O frontend, o servidor, o banco de dados e os workers se conectam, então medir onde começa a falha é mais útil do que reiniciar tudo.

O erro que evitaria

nslookup não reproduz toda a resolução do navegador: podem existir cache local, DNS-over-HTTPS e proxy. Se as respostas DNS coincidirem mas o site falhar, olhe o HTTP em vez de continuar modificando registros.

Quando trabalha com servidores de clientes, guarde um backup ou procedimento de reversão antes de mudanças que afetem dados, rede ou certificados. E se não souber quais permissões uma operação precisa, evite executar como root apenas para parar de mostrar erros.

Como isso se relaciona com o ArduMaker?

Antes de reconfigurar domínios no ArduMaker, contraste a resposta DNS de mais de uma origem e confirme o domínio exato. Separar sintomas evita cortes desnecessários.

Em um caso típico, você pode criar um VPS para o aplicativo, implantar via Git, associar domínio HTTPS e administrar o backend e os bancos de dados necessários. As ferramentas ajudam a centralizar operações, mas é preciso entender qual porta e processo cumpre cada função.

Perguntas que aparecem quando você testa

Como saber se a falha é de DNS ou do serviço? Consulte primeiro a resolução, depois a conexão na porta e, finalmente, a resposta do aplicativo. Essa ordem evita confundir problemas diferentes.

Posso expor um banco de dados para facilitar a manutenção? É melhor projetar acesso privado ou túneis autenticados quando possível. Expor uma porta não substitui as permissões do mecanismo nem o firewall.

O que devo documentar? A configuração esperada, como verificar e como voltar ao estado anterior. Esse documento ajuda mais do que uma lista de comandos sem contexto.

Referências

Em resumo: uma boa configuração de rede ou servidor é aquela que você consegue explicar, verificar e recuperar quando algo falha.