Corrigir o problema "Falha temporária na resolução de DNS" no Debian 12 com systemd-resolved

O erro Temporary failure in name resolutionsignifica que um aplicativo não conseguiu converter um nome de host, como `hostname`, deb.debian.orgem um endereço IP. No Debian 12 (Bookworm), isso não significa automaticamente que o DNS systemd-resolvedesteja com defeito. O Debian 12 não instala systemd-resolvedo DNS por padrão, e o gerenciamento do DNS pode ser feito diretamente pelo NetworkManager, ifupdown, ferramentas DHCP ou outro resolvedor. Se você habilitou o DNS deliberadamente systemd-resolved, a solução mais rápida é identificar qual camada está falhando antes de alterar a configuração.

Esta referência prática concentra-se em sistemas que usam, ou pretendem usar, o systemd-resolved systemd-resolved. A documentação do pacote Bookworm do Debian afirma que a instalação do systemd-resolved systemd-resolvedalterna /etc/resolv.confpara o gerenciamento do serviço. O próprio serviço fornece um stub DNS local 127.0.0.53e aceita informações DNS upstream da configuração global, da configuração de rede por link, do DHCP resolvectle de serviços de gerenciamento de rede. Consulte a página do pacote systemd-resolved do Debian e o manual do systemd-resolved do Debian .

Lista de verificação para diagnóstico rápido

1. Confirme se o problema é de DNS e não de conectividade geral.

Comece testando um nome de host e depois um endereço IP:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

Se a pesquisa do nome do host falhar, mas o teste de IP direto for bem-sucedido, o DNS é provavelmente o domínio com problema. Se ambos falharem, inspecione primeiro a interface, a rota, o gateway, a VLAN, a associação Wi-Fi, o firewall ou a rede upstream. Uma alteração no DNS não pode corrigir uma rota padrão ausente.

Para uma verificação de roteamento mais determinística, execute também:

ip address
ip route

Normalmente, você deve ter um endereço na interface esperada e uma rota padrão. O nome exato da interface pode ser enp1s0, ens160, eth0, ou algo diferente.

2. Verifique se o systemd-resolved está realmente em uso.

Não assuma que o problema esteja presente apenas porque a máquina usa o systemd. Verifique tanto o pacote quanto o serviço:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

Se o pacote estiver ausente e sua máquina tiver outro sistema de gerenciamento de DNS funcionando, a instalação systemd-resolvednão será automaticamente a solução correta. Se o sistema deveria usá-lo e o serviço estiver instalado, mas parado, habilite-o e inicie-o:

sudo systemctl enable --now systemd-resolved

Se esse comando falhar, verifique os registros antes de reiniciar o serviço repetidamente:

journalctl -u systemd-resolved -b --no-pager

3. Inspecione o arquivo /etc/resolv.conf antes de substituí-lo.

O erro de configuração mais comum é tratar /etc/resolv.confo arquivo como um arquivo isolado. Com o systemd-resolved systemd-resolved, ele pode operar em vários modos suportados. O modo stub recomendado pelo upstream vincula-se /etc/resolv.confa /run/systemd/resolve/stub-resolv.conf`/etc/sysctl 127.0.0.53.../run/systemd/resolve/resolv.conf

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Um arquivo regular não é automaticamente incorreto. O NetworkManager ou outro gerenciador de resolução pode intencionalmente ser o proprietário dele. No entanto, se este host foi projetado para usar o modo stub resolvido pelo systemd, um arquivo regular desatualizado, um link simbólico inválido ou um arquivo apontando para servidores de nomes inacessíveis pode causar falhas na pesquisa.

Restaure o link stub recomendado quando o modo stub for utilizado.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

A presença do nome nameserver 127.0.0.53no arquivo stub é esperada. Trata-se do listener local, não do servidor DNS upstream. Use ` resolvectl statussystemd-resolved` para verificar quais servidores upstream o systemd-resolved realmente contatará. Essa distinção está documentada no manual do Bookworm do systemd-resolved .

4. Verifique se o systemd-resolved possui um servidor DNS upstream utilizável.

Correr:

resolvectl status

Concentre-se no link que carrega a rota padrão. Uma configuração saudável normalmente deve mostrar um ou mais servidores DNS para esse link ou servidores DNS globais adequados. Se nenhum servidor DNS utilizável estiver presente, corrigir apenas o link simbólico não ajudará: o stub local não tem para onde enviar consultas.

Você pode testar o resolvedor diretamente:

resolvectl query debian.org

O manual do resolvectl no Debian documenta os comandos DNS específicos para cada link, utilizados para inspeção e resolução de problemas status.queryflush-caches

5. Se o NetworkManager for o proprietário da interface, corrija o DNS no perfil de conexão.

Em instalações de desktop e muitos sistemas Debian de uso geral, o NetworkManager pode fornecer informações de DNS por link para o systemd-resolved. Primeiro, identifique o perfil ativo e os valores de DNS atuais:

nmcli connection show --active
nmcli device show

Se o DHCP estiver fornecendo um servidor DNS inadequado, altere o perfil do NetworkManager em vez de editá-lo /etc/resolv.confapós cada reinicialização. Por exemplo, se a sua política de rede permitir servidores DNS públicos:

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

Substitua o nome do perfil e os servidores DNS por valores apropriados para sua rede. Redes corporativas, VPNs, ambientes Active Directory e configurações de DNS dividido geralmente exigem resolvedores internos; o DNS público pode quebrar nomes de host privados. A documentação oficial de configuração do NetworkManager descreve sua integração com o sistema systemd-resolved.

6. Se o systemd-networkd for o proprietário da interface, configure o DNS por link.

Para servidores que utilizam DHCP systemd-networkd, coloque as configurações de DNS no .networkarquivo correspondente em `/etc/dns/` /etc/systemd/network/. Um exemplo simples baseado em DHCP é:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=noIsso é importante quando você deseja ignorar especificamente os servidores DNS fornecidos pelo DHCP. Sem ele, o DNS do DHCP é usado por padrão. Domains=~.é um domínio somente de roteamento para a raiz do DNS, tornando esse link adequado para consultas que não correspondem a um domínio de roteamento mais específico. Não o adicione indiscriminadamente em sistemas com múltiplas interfaces de rede ou VPNs onde o DNS dividido é intencional.

sudo systemctl restart systemd-networkd
resolvectl status ens160

O comportamento de DNS=, Domains=, e DHCP UseDNS=está documentado no manual systemd.network do Debian Bookworm .

7. Use o resolved.conf global somente quando realmente desejar DNS em todo o sistema.

/etc/systemd/resolved.confOu, ainda, um arquivo de configuração /etc/systemd/resolved.conf.d/pode definir servidores DNS do sistema. Isso é útil para uma política em todo o host, mas é menos preciso do que a configuração por link em máquinas com VPNs, múltiplas interfaces ou zonas DNS privadas.

Geralmente, uma instalação local é mais simples do que editar o arquivo principal no estilo do fornecedor:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

Exemplo:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Em seguida, aplique-o:

sudo systemctl restart systemd-resolved
resolvectl status

O manual do Debian resolved.conf explica que DNS=ele fornece servidores DNS do sistema e que as configurações adicionais definidas pelo administrador /etc/systemd/resolved.conf.d/têm precedência sobre as configurações de menor prioridade.

8. Limpe os caches somente após corrigir a configuração subjacente.

Um cache desatualizado pode dificultar a resolução de problemas, mas a limpeza do cache não substitui a correção de um servidor upstream inacessível ou de uma configuração de link quebrada. Após fazer uma alteração real na configuração, você pode executar:

sudo resolvectl flush-caches
resolvectl query debian.org

A própria documentação do Systemd observa que os caches são normalmente limpos automaticamente quando há alterações na configuração de rede, portanto, a limpeza manual repetida não deve ser a sua principal solução.

9. Leia o registro do resolvedor quando a falha persistir.

Se resolvectl statusparecer razoável, mas as consultas ainda expirarem, inspecione o log do resolvedor local de inicialização:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

Procure por timeouts repetidos do servidor, alterações no servidor de fallback, falhas na validação do DNSSEC ou mensagens indicando redução de recursos do protocolo. Um resolvedor pode estar funcionando normalmente enquanto seu servidor upstream configurado estiver inacessível por meio de um firewall, VPN, política de roteamento ou ACL de rede.

10. Verifique o caminho de pesquisa completo.

Não pare após uma resolvectlconsulta bem-sucedida. Verifique o caminho usado pelos aplicativos normais:

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getentÉ útil porque as pesquisas de nomes de host da glibc seguem a hosts:linha em /etc/nsswitch.conf. Se resolvectl queryfor bem-sucedido, mas getentfalhar, inspecione essa configuração do NSS. O manual do nss-resolve do Debian descreve o módulo opcional libnss-resolvee uma ordem recomendada que pode rotear as pesquisas de nomes de host da glibc através do systemd-resolved, mantendo as alternativas.

Sintomas comuns e o local mais provável para procurar.

Ordem de reparo recomendada

1. Confirme se a conectividade básica de rede e a rota padrão existem.
2. Confirme se systemd-resolveda configuração para gerenciar DNS neste host realmente se aplica.
3. Verifique systemd-resolvedo estado do serviço e resolvectl status.
4. Verifique /etc/resolv.confa propriedade e o modo de link simbólico antes de alterá-los.
5. Se o modo stub for a intenção, restaure a stub-resolv.confconexão.
6. Corrija o DNS upstream no proprietário real: NetworkManager, systemd-networkd, DHCP, VPN ou configuração de resolução global.
7. Limpe o cache somente após a configuração ser corrigida.
8. Verifique com resolvectl, getent, e o aplicativo que apresentou falha originalmente.

O princípio fundamental é a propriedade: /etc/resolv.confo systemd-resolved e o gerenciador de rede fazem parte de uma mesma cadeia de resolução. Uma correção permanente altera o DNS na camada que o controla, em vez de substituir repetidamente o arquivo final gerado.