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

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que voce vai aprender

• Como determinar se "dominio nao resolve" ou "ficou lento de repente" e causado por DNS
• Como verificar as configuracoes DNS realmente usadas no Ubuntu (systemd-resolved / /etc/resolv.conf)
• Como identificar rapidamente sintomas relacionados a DNS (SSH/apt/curl todos falhando)

1. Sintomas tipicos de DNS

Conclusao: Quando SSH, curl e apt falham mas o IP direto funciona, DNS e o provavel culpado.

Quando o DNS quebra, parece que "tudo esta quebrado".

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

2. Primeira verificacao: Consegue resolver? (dig)

Conclusao: Execute dig example.com +short primeiro -- vazio ou timeout confirma que o DNS esta quebrado.

2-1. Verificacao minima (resultado A/AAAA)

$ dig example.com +short

Exemplo de saida (IP retornado):

93.184.216.34

Se vazio ou timeout, DNS e suspeito.

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

• NXDOMAIN: Nome nao existe (erro de digitacao/configuracao de zona)
• SERVFAIL: Falha do servidor DNS/erro de validacao (relacionado a DNSSEC)
• connection timed out; no servers could be reached: Nao consegue alcancar o servidor DNS (rede/firewall/configuracao)

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

Conclusao: 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 e um symlink)

3-1. Se resolvectl esta disponivel (prioridade)

$ resolvectl status

Pontos-chave:

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

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

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

Exemplo de saida:

nameserver 127.0.0.53

Este e o stub local do systemd-resolved. O DNS upstream real esta em resolvectl status.

4. Consultar um servidor DNS especifico

Conclusao: dig @8.8.8.8 funcionando mas DNS local falhando significa que o servidor DNS esta 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 esta quebrado/inalcancavel
• Falha mesmo com DNS especificado -> Problema upstream (rede/roteamento/saida)

5. Medindo a "lentidao" (sensacoes mentem)

Conclusao: Use dig +stats para o tempo de consulta -- lentidao consistente aponta para o servidor DNS.

"Resolve mas lento" acontece com frequencia. Meça com numeros.

5-1. Ver estatisticas do dig

$ dig example.com +stats

Procure esta linha no final:

Query time: 250 msec

5-2. Medir varias vezes com time

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

• So a primeira e lenta -> Cache/resolucao inicial
• Sempre lenta -> Qualidade do DNS/rede/MTU/problemas de saida

6. Padroes de causas comuns

Conclusao: Padroes: systemd-resolved morto, upstream lento, porta 53 bloqueada e atraso de search.

Padrao 1: systemd-resolved esta morto

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

Padrao 2: Servidor DNS esta fora/distante

dig @8.8.8.8 ... e rapido -> Seu servidor DNS esta lento/falhando

Padrao 3: Firewall bloqueando 53/UDP

dig @8.8.8.8 da timeout -> Pode nao ser possivel alcancar DNS externo

Padrao 4: Search domain causando atrasos

Hostnames curtos tentam multiplas buscas, causando lentidao.

7. Passos de recuperacao rapida (seguranca primeiro)

Conclusao: Registre resolvectl status antes de qualquer edicao em resolv.conf -- a alteracao e temporaria.

7-1. Primeiro, registre o estado atual

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

7-2. Correcao de emergencia: Editar /etc/resolv.conf diretamente (nao recomendado, mas rapido)

$ 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 interpretacao

Conclusao: NXDOMAIN significa sem nome; timeout com @8.8.8.8 significa saida bloqueada; lentidao e o servidor.

8-1. dig example.com retorna NXDOMAIN

Erro de digitacao no dominio, zona DNS nao configurada, problema de transferencia

8-2. dig @8.8.8.8 tambem da timeout

Nao consegue alcancar DNS externo / porta 53 bloqueada

8-3. "Resolve mas lento"

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

9. O que evitar

Conclusao: Nunca trate edicoes em resolv.conf como permanentes ou pule a medicao com dig +stats.

Nao faca: Tratar /etc/resolv.conf como permanente sem saber a causa

Frequentemente e sobrescrito, causando confusao apos reboot.

Nao faca: Assumir que problemas de DNS sao "bugs da aplicacao" e perder tempo

Se IP direto funciona, DNS e a causa provavel. Verifique o DNS primeiro.

Nao faca: Pular a medicao quando esta lento

Use dig +stats para ver o Query time. Sensacoes nao sao confiaveis.

# 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