Uma mensagem de MOTD 'inofensiva' e o troubleshooting de DNS que ela escondia

Nem todo aviso que aparece na tela de login é ruído. Esse caso começou com uma linha que qualquer um ignoraria — e terminou revelando duas causas diferentes empilhadas uma sobre a outra.

O sintoma

Ao logar via SSH no meu servidor doméstico (Ubuntu 22.04), o MOTD (mensagem do dia, exibida automaticamente no login) mostrava:

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

À primeira vista, parece cosmético — o Ubuntu só está tentando checar se há uma nova versão LTS disponível. Fácil de ignorar. Mas “check your internet connection” é uma mensagem genérica demais pra confiar de olhos fechados: podia ser falta de internet, podia ser DNS, podia ser só aquele domínio específico fora do ar. Decidi isolar a causa em vez de assumir.

Passo 1: é conexão ou é resolução de nome?

curl -v https://changelogs.ubuntu.com/meta-release-lts

Erro: Could not resolve host. Isso já muda o diagnóstico — não é um problema de conectividade (rota, firewall, proxy), é um problema de resolução DNS. O host não conseguia traduzir o nome pro IP antes mesmo de tentar conectar.

Passo 2: é só esse domínio, ou é DNS quebrado de verdade?

curl -v https://google.com

Mesmo erro. Isso descarta a hipótese de “domínio específico fora do ar” — o problema é geral, a máquina inteira estava sem resolução de DNS funcional.

Passo 3: resolver local vs. resolver externo

nslookup changelogs.ubuntu.com

SERVFAIL — o resolvedor local (127.0.0.53, o stub padrão do systemd-resolved) estava recebendo a consulta e falhando ao respondê-la. Pra confirmar que a internet em si estava OK, testei apontando direto pra um DNS externo:

nslookup changelogs.ubuntu.com 8.8.8.8

Resolveu normalmente. Conclusão nesse ponto: a internet funciona, a consulta DNS em si é resolvível — o problema está especificamente no resolvedor local da máquina, não na rede.

Passo 4: o comando que a maioria pula

É tentador, nesse ponto, ir direto pro /etc/resolv.conf procurar os servidores configurados. Só que hoje em dia, com systemd-resolved, esse arquivo geralmente é só um symlink pro stub interno (127.0.0.53) — ele não mostra qual interface está realmente provendo DNS nem por quê. O comando certo é outro:

resolvectl status

E aí apareceu a causa raiz: a única interface com Current Scopes: DNS era a tailscale0, apontando pro resolvedor MagicDNS do Tailscale (100.100.100.100). A interface física real, enp4s0f2, estava com Current Scopes: none — sem nenhuma responsabilidade de DNS. O Tailscale (com accept-dns=true, que é o comportamento padrão) tinha assumido controle global do DNS da máquina, e o resolvedor dele estava falhando ao repassar consultas pra domínios externos.

Passo 5: corrigindo a primeira causa

sudo tailscale set --accept-dns=false

Isso devolve o controle de DNS pras interfaces normais do sistema, em vez de deixar o Tailscale interceptar tudo globalmente.

Passo 6: a segunda causa, escondida atrás da primeira

Rodei resolvectl status de novo esperando ver tudo resolvido — e não estava. A interface enp4s0f2 continuava sem nenhum servidor DNS configurado. O Tailscale não era a única causa: ele só estava mascarando um segundo problema por baixo.

Descartei erro de configuração checando a conexão via NetworkManager:

nmcli connection show "Wired connection 1" | grep -iE "ipv4|dns"

A configuração estava correta — ipv4.method: auto, ipv4.ignore-auto-dns: no. O sistema deveria estar pegando DNS via DHCP normalmente. Ou seja, não era a config; era o lease de DHCP em si que estava incompleto ou velho demais, sem os servidores DNS que o roteador deveria ter fornecido.

Passo 7: forçando renovação do lease

sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1"

Ao subir a conexão de novo, um lease de DHCP novo (e completo) foi negociado. resolvectl status confirmou a interface física com servidores DNS válidos, e a resolução via stub 127.0.0.53 voltou a funcionar normalmente — sem precisar apontar pra DNS externo manualmente.

A lição

Duas causas diferentes, empilhadas: o Tailscale mascarando um DHCP quebrado por baixo. Se eu tivesse parado no primeiro achado (accept-dns=true sequestrando o DNS global) e desabilitado o Tailscale sem checar de novo, o servidor teria voltado a funcionar por acaso — mas o problema real (lease de DHCP incompleto) continuaria lá, pronto pra voltar na próxima reinicialização ou reconexão de rede.

A lição prática de troubleshooting: isole a causa em camadas antes de assumir a primeira explicação. É rede ou é DNS? É um domínio específico ou é geral? É o resolvedor local ou o externo? E o comando que fez toda a diferença aqui foi resolvectl status — ele mostra exatamente qual interface está provendo DNS e com que autoridade, algo que o velho hábito de abrir o /etc/resolv.conf direto simplesmente não revela mais no mundo do systemd-resolved. Sempre checar QUAL interface está realmente respondendo antes de assumir onde está o problema.