Troubleshooting de DNS no Ubuntu - Guia de dig, nslookup e resolvectl

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que você vai aprender

• Como determinar se "domínio não resolve" ou "ficou lento de repente" é causado por DNS
• Como verificar as configurações DNS realmente usadas no Ubuntu (systemd-resolved / /etc/resolv.conf)
• Como identificar rapidamente sintomas relacionados a DNS (SSH/apt/curl todos falhando)

1. Sintomas típicos de DNS

Conclusão: Quando SSH, curl e apt falham mas o IP direto funciona, DNS é o provável culpado.

Quando o DNS quebra, parece que "tudo está quebrado".

• ssh user@hostname não conecta (mas IP direto funciona)
• curl https://example.com morre com Could not resolve host
• apt update falha (não consegue resolver nomes)
• O servidor não consegue acessar APIs externas (mas ping às vezes funciona)

2. Primeira verificação: Consegue resolver? (dig)

Conclusão: Execute dig example.com +short primeiro -- vazio ou timeout confirma que o DNS está quebrado.

2-1. Verificação mínima (resultado A/AAAA)

$ dig example.com +short

Exemplo de saída (IP retornado):

93.184.216.34

Se vazio ou timeout, DNS é suspeito.

2-2. Leitura dos tipos de erro (3 mais comuns)

• NXDOMAIN: Nome não existe (erro de digitação/configuração de zona)
• SERVFAIL: Falha do servidor DNS/erro de validação (relacionado a DNSSEC)
• connection timed out; no servers could be reached: Não consegue alcançar o servidor DNS (rede/firewall/configuração)

3. Qual servidor DNS está sendo usado? (Armadilha do Ubuntu)

Conclusão: resolvectl status mostra o servidor DNS real -- resolv.conf frequentemente mostra o stub.

O Ubuntu usa diferentes fontes de DNS dependendo do ambiente:

• systemd-resolved gerencia (comum)
• NetworkManager gerencia
• /etc/resolv.conf diretamente (mas frequentemente é um symlink)

3-1. Se resolvectl está disponível (prioridade)

$ resolvectl status

Pontos-chave:

• DNS Servers: (alvos reais de consulta)
• Current DNS Server: (em uso atualmente)

3-2. Verificar /etc/resolv.conf (frequentemente é um symlink)

$ cat /etc/resolv.conf
$ ls -la /etc/resolv.conf

Exemplo de saída:

nameserver 127.0.0.53

Este é o stub local do systemd-resolved. O DNS upstream real está em resolvectl status.

4. Consultar um servidor DNS específico

Conclusão: dig @8.8.8.8 funcionando mas DNS local falhando significa que o servidor DNS está quebrado.

4-1. Google Public DNS

$ dig @8.8.8.8 example.com +short

4-2. Cloudflare

$ dig @1.1.1.1 example.com +short

4-3. Interpretando os resultados

• Funciona com DNS especificado -> Seu DNS configurado está quebrado/inalcançável
• Falha mesmo com DNS especificado -> Problema upstream (rede/roteamento/saída)

5. Medindo a "lentidão" (sensações mentem)

Conclusão: Use dig +stats para o tempo de consulta -- lentidão consistente aponta para o servidor DNS.

"Resolve mas lento" acontece com frequência. Meça com números.

5-1. Ver estatísticas do dig

$ dig example.com +stats

Procure esta linha no final:

Query time: 250 msec

5-2. Medir várias vezes com time

$ time dig example.com +short
$ time dig example.com +short

• Só a primeira é lenta -> Cache/resolução inicial
• Sempre lenta -> Qualidade do DNS/rede/MTU/problemas de saída

6. Padrões de causas comuns

Conclusão: Padrões: systemd-resolved morto, upstream lento, porta 53 bloqueada e atraso de search.

Padrão 1: systemd-resolved está morto

$ systemctl status systemd-resolved
$ sudo systemctl start systemd-resolved
$ sudo journalctl -u systemd-resolved -n 200

Padrão 2: Servidor DNS está fora/distante

dig @8.8.8.8 ... é rápido -> Seu servidor DNS está lento/falhando

Padrão 3: Firewall bloqueando 53/UDP

dig @8.8.8.8 dá timeout -> Pode não ser possível alcançar DNS externo

Padrão 4: Search domain causando atrasos

Hostnames curtos tentam múltiplas buscas, causando lentidão.

7. Passos de recuperação rápida (segurança primeiro)

Conclusão: Registre resolvectl status antes de qualquer edição em resolv.conf -- a alteração é temporária.

7-1. Primeiro, registre o estado atual

$ date
$ resolvectl status || true
$ cat /etc/resolv.conf

7-2. Correção de emergência: Editar /etc/resolv.conf diretamente (não recomendado, mas rápido)

$ sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak
$ printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\n" | sudo tee /etc/resolv.conf
$ dig example.com +short

Para reverter:

$ sudo cp -a /etc/resolv.conf.bak /etc/resolv.conf

8. Exemplos de erros e interpretação

Conclusão: NXDOMAIN significa sem nome; timeout com @8.8.8.8 significa saída bloqueada; lentidão é o servidor.

8-1. dig example.com retorna NXDOMAIN

Erro de digitação no domínio, zona DNS não configurada, problema de transferência

8-2. dig @8.8.8.8 também dá timeout

Não consegue alcançar DNS externo / porta 53 bloqueada

8-3. "Resolve mas lento"

Qualidade do servidor DNS, search domains, espera IPv6/AAAA, roteamento

9. O que evitar

Conclusão: Nunca trate edições em resolv.conf como permanentes ou pule a medição com dig +stats.

Não faça: Tratar /etc/resolv.conf como permanente sem saber a causa

Frequentemente é sobrescrito, causando confusão após reboot.

Não faça: Assumir que problemas de DNS são "bugs da aplicação" e perder tempo

Se IP direto funciona, DNS é a causa provável. Verifique o DNS primeiro.

Não faça: Pular a medição quando está lento

Use dig +stats para ver o Query time. Sensações não são confiáveis.

# 1) Consegue resolver?
dig example.com +short

# 2) Configuracoes DNS (assumindo systemd-resolved)
resolvectl status || true
cat /etc/resolv.conf

# 3) Consultar DNS especifico (comparacao)
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short

# 4) Medir lentidao
dig example.com +stats
dig A example.com +stats
dig AAAA example.com +stats