DNS Local no Linux Parou de Funcionar? Como Descobri que o Problema Não Era o dnsmasq

Quando o Sintoma Engana o Administrador

Poucas coisas são mais frustrantes em um homelab do que ver todos os serviços funcionando perfeitamente e, ao mesmo tempo, receber um erro de resolução DNS.

Foi exatamente isso que aconteceu quando os serviços internos hospedados em um servidor Fedora deixaram de ser acessíveis por seus nomes amigáveis.

Domínios como:

jellyfin.home
grafana.home
books.home
n8n.home

simplesmente deixaram de funcionar em uma workstation Fedora.

O detalhe interessante é que os serviços continuavam online.

O Jellyfin estava funcionando.

O Grafana estava funcionando.

O servidor respondia normalmente via SSH.

O celular continuava acessando tudo sem qualquer problema.

Quando apenas um equipamento apresenta falha enquanto todos os demais funcionam, o instinto inicial costuma ser procurar problemas no servidor. Porém, neste caso, seguir esse caminho levaria a horas de troubleshooting desnecessário.

A solução estava em outro lugar.

O Cenário da Infraestrutura

A arquitetura era relativamente simples.

Um Home Server executava o dnsmasq para fornecer resolução DNS interna.

O objetivo era permitir acesso aos serviços através de nomes fáceis de memorizar em vez de endereços IP.

Em vez de acessar:

https://192.168.100.10

o usuário acessava:

https://jellyfin.home

Essa pequena melhoria aumenta muito a usabilidade do ambiente.

A estrutura era:

Workstation
      ↓
Home Server (dnsmasq)
      ↓
Internet

Na teoria, qualquer consulta DNS deveria passar pelo dnsmasq.

Na prática, algo diferente estava acontecendo.

O Primeiro Sintoma

A falha apareceu quando tentativas de acesso aos serviços retornavam erros de resolução.

O navegador não encontrava os hosts.

Ferramentas como curl também falhavam.

O erro indicava claramente que o nome não estava sendo convertido para um endereço IP.

Nesse momento existem duas hipóteses principais:

Hipótese 1

O dnsmasq está quebrado.

Hipótese 2

A estação não está consultando o dnsmasq.

Antes de fazer qualquer alteração, era necessário descobrir qual das duas era verdadeira.

A Primeira Regra do Troubleshooting

Nunca assuma.

Teste.

Muitos administradores começam reiniciando serviços, alterando configurações ou recriando arquivos.

Isso frequentemente piora a situação.

A pergunta correta era:

O dnsmasq realmente está falhando?

Verificando o Suspeito Principal

A primeira etapa foi consultar diretamente o servidor DNS.

Em vez de perguntar ao sistema operacional qual endereço usar, a consulta foi enviada explicitamente para o servidor responsável pelo DNS local.

O resultado foi imediato.

O registro retornou corretamente.

O domínio interno era resolvido sem qualquer dificuldade.

Isso eliminou a principal suspeita.

O dnsmasq estava funcionando.

O banco de registros estava funcionando.

A rede estava funcionando.

O problema não estava no servidor.

Quando o Problema Não Está Onde Parece

Esse é um dos momentos mais importantes em qualquer troubleshooting.

Quando um teste direto funciona, o foco precisa mudar.

A pergunta deixa de ser:

Por que o dnsmasq não responde?

E passa a ser:

Por que a workstation não está usando o dnsmasq?

Essa mudança de perspectiva é o que separa uma investigação eficiente de uma longa sequência de tentativas aleatórias.

Seguindo o Caminho da Consulta DNS

Toda consulta DNS segue um fluxo.

Quando um usuário digita:

jellyfin.home

o pedido percorre várias camadas:

Aplicação
      ↓
Resolver local
      ↓
Servidor DNS configurado
      ↓
Resposta

Se o servidor DNS responde corretamente quando consultado diretamente, então alguma etapa intermediária está desviando o tráfego.

Era hora de descobrir qual.

O Papel do systemd-resolved

Nos sistemas Fedora modernos, a resolução DNS normalmente passa pelo systemd-resolved.

Ele atua como um intermediário entre as aplicações e os servidores DNS configurados.

Portanto, a próxima pergunta era simples:

Qual servidor DNS o Fedora está realmente utilizando neste momento?

A resposta revelou algo inesperado.

O Detalhe Que Mudou Tudo

Ao inspecionar a configuração ativa da resolução DNS, surgiu uma informação importante.

O servidor DNS atualmente utilizado não era o Home Server.

Era um endereço IPv6.

Algo semelhante a:

fe80::abcd:1234:5678:9999

Esse endereço não pertencia ao dnsmasq.

Pertencia ao roteador.

Ou seja:

Workstation
      ↓
Roteador

em vez de:

Workstation
      ↓
Home Server

O sistema estava ignorando o DNS local.

Por Que Isso Aconteceu?

Muitos roteadores modernos anunciam servidores DNS automaticamente através do IPv6.

Mesmo quando existe um DNS IPv4 configurado manualmente.

Dependendo da métrica utilizada pelo NetworkManager e pelo systemd-resolved, o DNS IPv6 pode receber prioridade.

O resultado é que o computador passa a consultar o roteador.

E o roteador obviamente não conhece registros internos como:

jellyfin.home
grafana.home
books.home

Portanto, a consulta falha.

Como Confirmar a Suspeita

Antes de alterar qualquer configuração, era necessário provar que aquele endereço IPv6 realmente pertencia ao roteador.

A verificação mostrou exatamente isso.

O DNS ativo estava apontando para o gateway da rede.

Nesse momento a investigação estava praticamente encerrada.

O comportamento fazia sentido.

Todos os sintomas se encaixavam.

Montando o Quebra-Cabeça

Observe como todas as peças passaram a se encaixar:

O dnsmasq respondia

Logo, ele estava saudável.

O celular funcionava

Logo, a rede não estava quebrada.

O SSH funcionava

Logo, o servidor estava acessível.

Apenas os domínios internos falhavam

Logo, era um problema de resolução.

O Fedora utilizava o roteador como DNS

Logo, os registros locais nunca eram encontrados.

O culpado havia sido identificado.

A Correção

Agora que a causa raiz estava clara, a solução tornou-se simples.

Não era necessário reinstalar nada.

Não era necessário modificar o dnsmasq.

Não era necessário alterar registros DNS.

O objetivo era apenas impedir que o Fedora utilizasse o DNS IPv6 anunciado automaticamente pelo roteador.

Após remover essa prioridade automática e reconectar a interface de rede, a workstation voltou a utilizar o DNS interno corretamente.

Como Validar a Solução

Após qualquer correção, é fundamental validar o resultado.

Muitos administradores cometem o erro de assumir que tudo está resolvido porque uma única consulta funcionou.

A validação correta ocorreu em três etapas.

1. Verificar o DNS ativo

O resolvedor passou a apontar para o Home Server.

2. Testar um domínio interno

O domínio voltou a resolver corretamente.

3. Testar um domínio externo

Sites da internet continuaram funcionando normalmente.

Somente após esses três testes foi possível considerar o incidente encerrado.

A Arquitetura Final

Depois da correção, o fluxo voltou ao comportamento esperado.

Para serviços internos

Workstation
      ↓
systemd-resolved
      ↓
dnsmasq
      ↓
Domínios .home

Para a internet

Workstation
      ↓
systemd-resolved
      ↓
dnsmasq
      ↓
DNS público
      ↓
Internet

O Risco de Ter um DNS Centralizado

Durante a investigação surgiu uma observação importante.

Quando toda a resolução DNS depende do Home Server, ele se torna um componente crítico.

Caso o servidor fique indisponível:

os domínios internos deixam de funcionar;
a resolução DNS da internet deixa de funcionar;
os serviços continuam online, mas apenas por IP.

Isso não é necessariamente um problema.

Na verdade, é um comportamento esperado em muitas infraestruturas.

Mas é algo que deve ser conhecido antes que uma falha aconteça.

A Principal Lição Aprendida

A maior lição desse incidente não tem relação com dnsmasq.

Nem com IPv6.

Nem com Fedora.

A verdadeira lição é metodológica.

Quando um domínio interno para de resolver, a tendência é culpar imediatamente o servidor DNS.

Mas a pergunta correta é:

Quem está respondendo às consultas DNS neste momento?

Em poucos minutos essa pergunta revelou toda a causa raiz do problema.

O dnsmasq estava perfeito.

O erro estava no caminho percorrido pela consulta.

E esse é exatamente o tipo de raciocínio que diferencia troubleshooting de tentativa e erro.

Resumo do Diagnóstico

Os domínios .home deixaram de funcionar.
O dnsmasq respondeu corretamente quando consultado diretamente.
O problema não estava no servidor DNS.
A workstation utilizava um DNS IPv6 anunciado pelo roteador.
O roteador não possuía os registros internos.
As consultas nunca chegavam ao dnsmasq.
Após remover a prioridade automática do DNS IPv6, a resolução voltou a funcionar.

Essa sequência mostra uma verdade importante da administração Linux:

A maioria dos problemas de rede não está no serviço que aparentemente falhou. Está no caminho que os pacotes percorrem até ele.