Tutoriais de VPS
O que fazer quando a resolução DNS do VPS falha (2026): checklist de systemd-resolved, resolvectl e resolv.conf
O VPS consegue pingar um IP, mas não resolve nomes de domínio; o problema geralmente está no resolver DNS, no /etc/resolv.conf, no systemd-resolved, no DNS entregue por DHCP ou no estado do cache. Este artigo organiza um checklist de diagnóstico de DNS na ordem de ping em IP, dig, resolvectl, 127.0.0.53, logs e correção temporária.
Existe um tipo de falha de VPS bem chata: o servidor parece não estar sem rede, ping 1.1.1.1 funciona, o SSH também conecta, mas apt update, curl https://example.com e as requisições das aplicações a APIs de terceiros dão erro em tudo.
O erro geralmente aparece assim:
Temporary failure in name resolution
Could not resolve host
Name or service not known
Nessa hora, não se apresse em reiniciar a máquina inteira. Muitas vezes não é a rede do VPS que caiu, mas a resolução DNS que parou de funcionar.
Em resumo, se o IP funciona mas o domínio não, é que "a estrada continua lá, mas a lista telefônica quebrou". Este artigo segue uma ordem de diagnóstico: como confirmar se é DNS, como verificar o systemd-resolved, por que o /etc/resolv.conf quebra, o que é o 127.0.0.53, como recuperar temporariamente e, por fim, como evitar que ele seja sobrescrito de novo na próxima vez.
Não fique adivinhando no primeiro passo; faça um teste comparativo direto.
Primeiro, pingue um IP:
ping -c 3 1.1.1.1
Depois, pingue um domínio:
ping -c 3 example.com
Se o IP funciona e o domínio não, muito provavelmente é um problema de resolução DNS.
Depois compare com curl:
curl -I https://1.1.1.1
curl -I https://example.com
O https://1.1.1.1 pode dar erro de TLS por incompatibilidade de domínio do certificado, mas, desde que consiga conectar ao outro lado, a camada de rede está mais ou menos intacta. O que realmente importa é ver se a resolução do domínio falha.
Se o dig estiver instalado, fica mais direto:
dig example.com
Se o DNS padrão do sistema não resolver, especifique um DNS público:
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
Se o dig @1.1.1.1 example.com resolve e o dig example.com não, o serviço de DNS público está sem problema e a falha está na configuração de resolução local deste VPS.
Em sistemas como Ubuntu 20.04/22.04/24.04, o componente comum é o systemd-resolved. Primeiro veja o status:
resolvectl status
Preste atenção em alguns pontos:
- Se o Global tem DNS Servers
- Se a interface de rede atual tem DNS Servers
- Se o DNSSEC está yes, no ou allow-downgrade
- Se o DNSOverTLS está ativado
- Qual interface é o DefaultRoute atual
Também dá para consultar um domínio diretamente:
resolvectl query example.com
Se isso falhar mas o dig @1.1.1.1 example.com funcionar, o problema está concentrado no resolver local ou na configuração DNS da interface.
Depois veja o status do serviço:
systemctl status systemd-resolved --no-pager
Veja os logs recentes:
journalctl -u systemd-resolved --since "30 minutes ago" --no-pager
Se estiver diagnosticando uma falha em produção, dá para acompanhar em tempo real:
journalctl -u systemd-resolved -f
A documentação de diagnóstico de DNSSEC do Ubuntu também usa combinações de resolvectl, dig e journalctl para localizar problemas de resolução; esse conjunto de comandos é bem mais confiável do que "tentar reiniciar".
Muita gente, ao ver só esta linha no /etc/resolv.conf pela primeira vez, acha que o DNS foi alterado indevidamente:
nameserver 127.0.0.53
Na verdade, isso geralmente é o stub resolver local do systemd-resolved. As aplicações enviam as requisições DNS para 127.0.0.53, e o systemd-resolved as encaminha para o DNS upstream real.
Primeiro veja o que o /etc/resolv.conf realmente é:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
Um dos casos normais comuns é ele apontar para:
/run/systemd/resolve/stub-resolv.conf
que contém:
nameserver 127.0.0.53
Alguns sistemas apontam diretamente para:
/run/systemd/resolve/resolv.conf
que contém o DNS upstream real. Os dois modos podem ser normais; o importante é que estejam de acordo com a forma de gerenciamento de rede do seu sistema.
O que é realmente perigoso:
- O
/etc/resolv.confestar escrito à mão e ser sobrescrito após reiniciar - O arquivo apontar para um caminho inexistente
- O nameserver estar configurado com um endereço interno inacessível
- Haver apenas DNS IPv6, mas a rota IPv6 do VPS não funcionar
- Painel, VPN, Docker e cloud-init disputarem quem altera o DNS
Para falhas de DNS, não rode só um comando. Você pode seguir esta ordem:
dig example.com
dig @127.0.0.53 example.com
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
Alguns resultados são fáceis de interpretar:
| Resultado | Explicação |
|---|---|
@1.1.1.1 funciona, o padrão falha | Problema no resolver local / resolv.conf |
@127.0.0.53 falha, @1.1.1.1 funciona | Problema no systemd-resolved ou na configuração upstream dele |
| Todos os DNS públicos falham | Pode ser o próprio domínio, o UDP/TCP 53 de saída do VPS ou uma política de rede |
| Só um domínio falha | Pode ser DNSSEC, DNS autoritativo, configuração do domínio ou cache |
| O registro A funciona, o AAAA trava | A configuração de DNS/rede IPv6 pode ter armadilhas |
Alguns provedores de VPS ou redes corporativas bloqueiam UDP 53; também dá para tentar TCP:
dig +tcp @1.1.1.1 example.com
Se o UDP falha e o TCP funciona, desconfie de firewall, política da operadora ou regras locais.
Quando o serviço em produção está dando erro, o objetivo é restaurar a resolução primeiro e depois procurar a causa raiz com calma.
Se você sabe o nome da interface, por exemplo eth0, dá para configurar temporariamente:
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 '~.'
Depois teste:
resolvectl query example.com
dig example.com
curl -I https://example.com
Se a interface não se chama eth0, primeiro veja:
ip link
resolvectl status
Esse tipo de configuração com resolvectl dns é mais voltado ao runtime e serve para emergências. Para valer de forma permanente, ainda é preciso tratar no netplan, NetworkManager, cloud-init ou na configuração de rede do sistema.
Se quiser desfazer a configuração temporária na interface:
sudo resolvectl revert eth0
Às vezes não é que a configuração DNS esteja totalmente errada, mas o cache ou o estado de sondagem de recursos do servidor estão anormais.
Dá para limpar o cache DNS:
sudo resolvectl flush-caches
Depois redefinir a sondagem de recursos do servidor DNS:
sudo resolvectl reset-server-features
E consultar de novo:
resolvectl query example.com
O manual oficial do resolvectl traz operações como flush caches, reset server features, definir DNS por interface e reverter a configuração da interface. No diagnóstico, use primeiro esses comandos delimitados; não saia apagando arquivos de configuração de qualquer jeito.
Se o systemd-resolved estiver em estado anormal, dá para reiniciá-lo:
sudo systemctl restart systemd-resolved
E ver imediatamente:
systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query example.com
Não é recomendado ter o reboot como primeira reação. Reiniciar o VPS inteiro interrompe o negócio e, se o /etc/resolv.conf ou a configuração do netplan já estavam errados, o problema continua após o reinício.
Se melhorar depois de reiniciar o serviço, também pergunte: por que ele quebrou? Foi o cache, o DNS upstream, o DNS entregue por DHCP, o DNSSEC ou alguma ferramenta que alterou a configuração?
Muitos tutoriais ensinam a fazer assim:
sudo nano /etc/resolv.conf
e depois escrever:
nameserver 8.8.8.8
nameserver 1.1.1.1
Pode funcionar por um tempo, mas costuma ser sobrescrito pelo NetworkManager, netplan, systemd-resolved, cloud-init ou pelo cliente DHCP.
Se for só uma emergência, pode escrever temporariamente, mas saiba que pode não persistir. O mais estável é descobrir quem gerencia a rede.
No Ubuntu, o comum é o netplan:
ls /etc/netplan/
Veja a configuração:
sudo cat /etc/netplan/*.yaml
Se for netplan, dá para configurar nameservers na interface correspondente, por exemplo:
network:
version: 2
ethernets:
eth0:
dhcp4: true
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
Depois de alterar, verifique primeiro e só então aplique:
sudo netplan try
sudo netplan apply
Alterar o netplan em um VPS remoto exige muito cuidado. O netplan try dá a chance de reverter; não se deixe ficar sem acesso direto.
Muitos VPS têm a configuração de rede escrita pelo cloud-init no primeiro boot. Se você alterou o netplan à mão e, depois de um tempo, após reiniciar ou reconstruir, ela foi sobrescrita, vale olhar o cloud-init.
Arquivos comuns:
ls /etc/cloud/cloud.cfg.d/
Se você claramente não quer que o cloud-init gerencie a rede, alguns sistemas usam uma configuração parecida com:
network: {config: disabled}
Mas não copie isso sem pensar. Os templates dos provedores de nuvem são diferentes, e desativar o gerenciamento de rede do cloud-init pode afetar alterações posteriores de IP, troca de placa de rede ou reconstrução da instância. Antes de mexer nisso em uma máquina de produção, confirme a documentação do provedor de nuvem e a configuração de rede atual.
Para o usuário comum, o mais seguro é: primeiro descobrir se o DNS vem do DHCP, do netplan, do NetworkManager ou do cloud-init, e só então decidir onde alterar.
Se apenas domínios específicos falham na resolução e os resultados de DNS públicos são inconsistentes, dá para desconfiar de DNSSEC, DNS autoritativo ou cache.
Veja o status do resolved:
resolvectl status
Veja os logs relacionados a DNSSEC:
journalctl -u systemd-resolved --since "30 minutes ago" --no-pager
Use o dig para ver as informações de DNSSEC:
dig example.com +dnssec
Depois especifique upstreams diferentes:
dig @1.1.1.1 example.com +dnssec
dig @8.8.8.8 example.com +dnssec
Se falhar apenas com a validação DNSSEC ativada, pode ser que a configuração DNSSEC do domínio esteja quebrada, ou que a rede intermediária ou o DNS upstream tenham suporte incompleto.
Não é recomendado desativar todo o DNSSEC por muito tempo por causa de um único domínio. O melhor é primeiro confirmar se é um problema do DNS autoritativo do domínio e depois decidir se faz um downgrade temporário.
O host conseguir resolver não significa que o contêiner também consiga.
Entre no contêiner para testar:
docker exec -it 容器名 sh
nslookup example.com
cat /etc/resolv.conf
O Docker gera por padrão o próprio /etc/resolv.conf para os contêineres. Se o contêiner não acompanhar a mudança de DNS do host, ou se o daemon do Docker estiver configurado com um DNS errado, as aplicações dentro do contêiner vão dar Could not resolve host.
Dá para ver a configuração do daemon do Docker:
sudo cat /etc/docker/daemon.json
Se quiser fixar o DNS para o Docker, uma forma comum é:
{
"dns": ["1.1.1.1", "8.8.8.8"]
}
Depois de alterar, é preciso reiniciar o Docker:
sudo systemctl restart docker
Atenção: reiniciar o Docker afeta os contêineres; em produção, é preciso agendar uma janela.
BT Panel, 1Panel, clientes VPN, ferramentas de proxy e ferramentas de penetração de rede interna podem alterar o DNS ou as rotas.
No diagnóstico, veja as alterações recentes:
stat /etc/resolv.conf
ls -lt /etc/netplan/
journalctl --since "2 hours ago" --no-pager | grep -i dns
Se a falha aconteceu depois de você instalar uma VPN, alterar um security group, instalar um painel ou ajustar a rede do Docker, revise primeiro essa alteração. Problemas de DNS muitas vezes não são "quebrou de repente", mas sim alguma ferramenta que alterou a configuração de rede por você.
Se a produção está fora do ar, siga esta ordem:
ping -c 3 1.1.1.1para ver se o IP funcionaping -c 3 example.compara ver se a resolução do domínio falhadig @1.1.1.1 example.compara verificar se o DNS público consegue resolverresolvectl statuspara ver o DNS e a interface atuaisreadlink -f /etc/resolv.confpara ver para onde o resolv.conf apontajournalctl -u systemd-resolved --since "30 minutes ago"para ver os logssudo resolvectl flush-cachespara limpar o cachesudo resolvectl reset-server-featurespara redefinir o estado de sondagemsudo resolvectl dns eth0 1.1.1.1 8.8.8.8para especificar o DNS temporariamenteresolvectl query example.compara verificar a recuperação- Depois volte e corrija a configuração persistente do netplan / NetworkManager / cloud-init
O ponto principal desse fluxo é separar por camadas primeiro: se a rede funciona, se o resolver local está bom, se o DNS upstream consegue resolver e se a configuração será sobrescrita.
- O IP funciona e o domínio não, confirmando que é a direção do DNS
- O
dig @1.1.1.1 example.comconsegue verificar o DNS público - O
resolvectl statusmostrou o DNS da interface atual - O status do serviço
systemd-resolvedestá normal - O
/etc/resolv.confaponta para algo razoável, sem links quebrados - O
127.0.0.53é um stub resolver, não é um erro por si só - O cache foi limpo e o reset server features foi feito
- A resolução voltou após a configuração DNS temporária
- A configuração persistente foi tratada no netplan / NetworkManager / cloud-init
- O DNS dentro dos contêineres Docker também foi testado separadamente
- Não se usou o
rebootpara mascarar a causa raiz
Falhas de DNS parecem misteriosas, mas na verdade se dividem em poucas camadas: a quem a aplicação pergunta, para quem o systemd-resolved encaminha, se o DNS upstream responde e se a configuração será sobrescrita por outras ferramentas. Desde que o IP funcione, não se apresse em suspeitar que o VPS inteiro quebrou; primeiro verifique a cadeia de resolução camada por camada.