Linux / Comando resolvectl: consultar DNS global e por interface

O comando resolvectl consulta os servidores DNS, os domínios por interface e os resultados de resolução de nomes do systemd-resolved. Ele é útil para investigar DNS — o Sistema de Nomes de Domínio — quando esse serviço realmente participa da resolução do sistema; não representa automaticamente o caminho usado por toda aplicação.

Uma conexão Ethernet, uma rede sem fio e uma VPN podem ter servidores e regras diferentes. VPN significa rede privada virtual. No DNS dividido, ou split DNS, o domínio consultado ajuda a determinar por qual conexão a consulta será encaminhada. Por isso, ler apenas um endereço de servidor pode esconder parte da configuração.

Sintaxe e ambiente necessário

resolvectl [comando] [nome ou interface]

Os colchetes indicam argumentos descritivos. Confirme a versão com resolvectl --version e consulte man resolvectl na máquina Linux em análise. As funções disponíveis dependem da versão instalada e da integração da distribuição.

Antes de investigar uma falha, verifique se o systemd-resolved está presente e ativo e qual serviço gerencia a rede. O guia do systemctl explica como consultar estados de serviços. A ausência do resolvectl ou uma falha de comunicação com o serviço não prova, por si só, que o DNS de todas as aplicações esteja quebrado. Não habilite outro resolvedor apenas para reproduzir este guia.

Consultar configurações, nomes e estatísticas

Ver a configuração efetiva

resolvectl status

Leia tanto a parte global quanto os blocos de interface. Registre servidores, domínios e as conexões às quais pertencem, incluindo a VPN quando houver. O nome de interface e seu índice variam de máquina para máquina. O estado mostra a configuração atual do resolved, sem certificar que cada servidor responderá à próxima consulta.

Resolver um nome pelo serviço

resolvectl query example.com

O nome example.com é mantido pela IANA para exemplos. Uma consulta normal de nome procura endereços IPv4 e IPv6 conforme o contexto e pode mostrar o protocolo e a interface relacionados ao resultado. Os endereços e a apresentação não devem ser tratados como valores fixos.

Uma resposta pode vir de cache ou de uma fonte local; executar query não garante um novo pacote ao servidor DNS externo. Mesmo um resultado indicado como autenticado não é, isoladamente, prova de validação DNSSEC de um registro público: o resolved também confia em determinadas fontes locais. DNSSEC é o conjunto de extensões de segurança do DNS. Resolver um nome tampouco comprova que o site ou outro serviço esteja acessível.

Se uma aplicação discordar do resultado, compare os caminhos de resolução. Ela pode ter cache próprio ou usar outro resolvedor. A consulta deste comando descreve o caminho do systemd-resolved, não o comportamento obrigatório de um navegador ou de um contêiner.

Observar os contadores do resolvedor

resolvectl statistics

As estatísticas ajudam a acompanhar o trabalho do serviço, incluindo resolução, cache e validação quando disponíveis. Registre uma referência antes de repetir um teste e compare depois, considerando outras consultas feitas ao mesmo tempo. Os contadores agregados não identificam, sozinhos, qual aplicação gerou cada evento nem medem todos os pedidos DNS da máquina.

Distinguir DNS global, por interface e dividido

Volte ao estado quando precisar relacionar um resultado à configuração:

resolvectl status

Trecho ilustrativo de saída; não é a configuração medida neste artigo:

Global
    Current DNS Server: 192.0.2.53
Link 2 (eth0)
    DNS Servers: 192.0.2.53

Global e Link 2 (eth0) representam escopos diferentes. O índice 2 e o nome eth0 são exemplos. O endereço 192.0.2.53 pertence à faixa de documentação TEST-NET-1 definida na RFC 5737; não o configure como servidor DNS funcional.

O campo Current DNS Server é uma indicação do escopo exibido, não uma promessa de que esse mesmo servidor responderá a todos os nomes. Regras de domínio e as interfaces elegíveis participam do encaminhamento. A presença simultânea de configuração global e por interface exige observar ambas.

Um domínio de busca pode completar um nome curto. Um domínio de roteamento precedido por ~ seleciona o caminho sem acrescentar esse sufixo ao nome. Para consultas DNS unicast, a correspondência de domínio mais específica tem preferência; pode haver mais de uma conexão com a mesma correspondência. Sem correspondência, entram as regras de rota padrão para DNS e a configuração global. A documentação do systemd-resolved detalha esses casos.

Compare um nome público e, somente quando autorizado, o nome interno envolvido no problema. Uma consulta pública bem-sucedida não testa a zona interna de uma VPN. Evite substituir a configuração por um servidor público como primeira tentativa: isso pode perder a resolução interna e encaminhar nomes privados para fora da rede prevista.

Comandos de leitura e comandos que mudam o estado

Não acrescente servidores ou domínios aos comandos de consulta sem planejar a mudança. Limpar o cache do resolved não altera os registros no servidor autoritativo e não garante limpar o cache de cada aplicação. Registre os resultados anteriores antes de modificar essa referência.

Investigar sem sobrescrever a política de DNS

1. Confirme o uso do systemd-resolved e registre o estado global e das interfaces, inclusive a VPN. Anote qual nome falha e em qual aplicação.
2. Consulte o mesmo nome pelo resolvectl e compare resultado, erro e contexto de rede. Uma consulta bem-sucedida deve ser separada de uma conexão bem-sucedida à aplicação.
3. Confira domínios de busca e roteamento e como /etc/resolv.conf está integrado. Relacione a falha ao escopo correspondente antes de trocar um servidor ou limpar caches.
4. Se houver uma mudança autorizada, identifique o gerenciador responsável e registre os valores anteriores e como restaurá-los. Valide novamente os nomes públicos e internos necessários após a mudança.

O arquivo /etc/resolv.conf pode apontar para o stub local 127.0.0.53, para uma lista de servidores ou ser gerenciado por outro componente. Uma lista tradicional não expressa toda a política por interface. Confira também o destino do link simbólico, quando houver, e não substitua o arquivo apenas porque contém um endereço de loopback.

Configurações fornecidas pelo gerenciador de rede ou pelo DHCP, o Protocolo de Configuração Dinâmica de Hosts, podem ser reaplicadas. Distingua um ajuste feito em tempo de execução da configuração persistente administrada pelo sistema; documente e restaure a origem correta dos valores.

Na verificação deste artigo, o resolvectl não estava disponível no Git Bash do Windows 11. Os três comandos distintos passaram apenas pela análise de sintaxe do Bash; o exemplo status aparece duas vezes no texto. Não houve consulta pelo systemd-resolved, alteração de DNS ou limpeza de cache, e a saída apresentada é ilustrativa.

Pergunta frequente

O que verificar se resolvectl não existir ou não funcionar?

Identifique o serviço de resolução realmente usado, seu estado e a relação com /etc/resolv.conf. Algumas distribuições ou ambientes não usam systemd-resolved. Um comando ausente ou um serviço indisponível não basta para concluir que toda resolução de nomes falhou; compare com o caminho da aplicação afetada.

Manual de referência

O manual oficial do resolvectl descreve os comandos. Confira também o manual instalado para aplicar as opções compatíveis com a versão do seu sistema.