DNS local e nomes de dispositivos: acessar o servidor pelo nome

Por que números funcionam e nomes não, por padrão

Na rede, aparelhos só se encontram por endereço IP. Nomes são uma camada de conveniência construída por cima, e alguém precisa fazer a tradução de “servidor” para “192.168.0.50”. Na internet, essa tradução é o DNS, um sistema distribuído de servidores que responde “qual é o IP deste nome?”. Na sua casa, o roteador repassa essas perguntas ao DNS da operadora ou a um DNS público, e eles conhecem os nomes do mundo todo, mas não fazem ideia de quem é “servidor” na sua sala.

Por isso, dar um nome ao servidor exige escolher quem vai responder por ele dentro de casa. Há cinco mecanismos possíveis, e eles não se excluem: é comum usar dois ao mesmo tempo. Todos partem do mesmo pré-requisito: o servidor precisa ter um endereço que não muda, como configurado em IP fixo, DHCP e reserva de endereço. Um nome que aponta para um IP móvel é só um jeito mais elegante de errar.

Antes de qualquer mecanismo, defina o nome do próprio servidor. No Ubuntu Server e no Debian:

sudo hostnamectl set-hostname servidor
hostnamectl

O primeiro comando grava o nome; o segundo mostra como ficou. Use só letras minúsculas, números e hífen, sem acento nem espaço: servidor, nas-sala, pi-backup. No OpenMediaVault, o mesmo ajuste fica em Rede › Geral. Esse nome é o que o servidor vai anunciar nos mecanismos a seguir.

Como a resolução de nomes acontece

Quando você digita smb://servidor ou ssh maria@servidor, o sistema operacional do cliente percorre uma sequência de fontes até alguma responder. A ordem exata varia por sistema, mas o esquema é sempre parecido com o diagrama abaixo, e entender essa fila explica a maioria dos “funciona no notebook e não funciona na TV”.

mDNS: nome.local sem instalar servidor nenhum

mDNS (DNS multicast) inverte a lógica: em vez de perguntar a um servidor central, o cliente grita para a rede “quem é servidor.local?”, e o próprio servidor responde “sou eu, 192.168.0.50”. Não há nada para configurar no roteador nem nos clientes, porque macOS, Linux e Windows 10 e 11 já falam mDNS por padrão. O nome é sempre o hostname seguido de .local.

No Ubuntu Server, o serviço que responde a essas perguntas é o Avahi, que não vem instalado por padrão; no Raspberry Pi OS e no OpenMediaVault ele já costuma estar presente. Para instalar e verificar:

sudo apt install avahi-daemon
systemctl status avahi-daemon

O primeiro comando instala e ativa o serviço; o segundo confirma que está rodando. De outro aparelho da rede, teste com ping servidor.local. Se o firewall ufw estiver ativo no servidor, libere a porta do mDNS: sudo ufw allow 5353/udp.

Limitações: mDNS só funciona dentro da mesma rede local (o “grito” não atravessa o roteador nem uma VPN), algumas TVs e aparelhos de automação não o entendem, e redes Wi-Fi com “isolamento de clientes” ligado bloqueiam a pergunta. Para a maior parte das casas, porém, é a solução mais barata e suficiente para notebooks e celulares.

Nome definido pelo roteador

Quando o servidor pede endereço por DHCP, ele informa seu hostname ao roteador. Alguns roteadores aproveitam essa informação para responder a consultas DNS internas: digitar servidor ou servidor.lan resolve para o IP correto porque o roteador, que é o DNS da casa, conhece a lista. Roteadores com firmware OpenWrt fazem isso bem; muitos aparelhos de operadora apenas exibem o nome na lista de dispositivos, sem responder por ele.

O teste é rápido, de qualquer computador da rede:

nslookup servidor

Se vier um endereço, o roteador resolve nomes e você tem um mecanismo gratuito que funciona até em aparelhos sem mDNS. Se vier “não foi possível encontrar”, o roteador não faz esse papel, e não há como forçá-lo sem trocar o firmware. Note que o nome via roteador depende de o servidor ter pedido o endereço por DHCP; se você configurou IP estático no sistema operacional, o roteador pode nem saber que ele existe, mais um motivo para preferir a reserva DHCP.

O arquivo hosts: um nome por aparelho, à mão

Todo sistema operacional tem um arquivo de texto com pares “endereço nome” consultado antes de qualquer DNS. Editá-lo é o jeito mais antigo e mais previsível de dar nome ao servidor: não depende de rede, de roteador nem de serviço. A desvantagem é óbvia: a edição precisa ser repetida em cada computador, e se o IP do servidor mudar, cada arquivo fica errado.

• Windows: C:\Windows\System32\drivers\etc\hosts. Abra o Bloco de Notas como administrador (botão direito › Executar como administrador) e, nele, abra o arquivo escolhendo “Todos os arquivos” no filtro.
• Linux e macOS: /etc/hosts, editado com sudo nano /etc/hosts.

Em qualquer deles, acrescente uma linha por servidor:

192.168.0.50   servidor   servidor.casa

O primeiro campo é o IP; os seguintes são os nomes (pode haver mais de um). Salve e teste com ping servidor. No Windows, se o nome antigo continuar sendo usado, limpe o cache com ipconfig /flushdns; no macOS, com sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Use o arquivo hosts para os dois ou três computadores que acessam o servidor todo dia e aceite que celulares e TVs ficarão de fora: eles não permitem editar esse arquivo sem desbloqueio.

Servidor DNS local: Pi-hole ou AdGuard Home

A solução completa é ter um servidor DNS seu, que todos os aparelhos consultam. Ele responde pelos nomes da casa que você cadastrar e repassa o resto para a internet. Os dois programas mais usados para isso em casa, Pi-hole e AdGuard Home, nasceram como bloqueadores de anúncios em nível de rede, e os registros locais vieram de brinde. Ambos rodam no próprio servidor (direto ou em contêiner, como em Docker para iniciantes) ou num Raspberry Pi dedicado.

1. Instale o Pi-hole ou o AdGuard Home seguindo a documentação oficial de cada um. Os dois têm instaladores guiados e um painel web.
2. Cadastre os nomes locais. No Pi-hole: Local DNS › DNS Records, informe o nome e o IP. No AdGuard Home: Filtros › Reescritas de DNS, com o mesmo par. Use um sufixo reservado para redes domésticas, como servidor.home.arpa (o sufixo definido para esse fim) ou servidor.lan; nunca termine em .local, que é exclusivo do mDNS e vai gerar conflitos.
3. Faça os aparelhos usarem o novo DNS. Na página do roteador, na seção de DHCP, troque o servidor DNS distribuído aos clientes pelo IP do Pi-hole ou AdGuard Home. Cada aparelho passa a usá-lo quando renovar o endereço (ou ao reconectar). Se o roteador não permitir mudar o DNS do DHCP, configure o DNS manualmente em cada aparelho importante, ou considere trocar o roteador.
4. Teste de um cliente. nslookup servidor.home.arpa no Windows ou getent hosts servidor.home.arpa no Linux devem retornar o IP do servidor. Se retornarem o IP do DNS da operadora ou nada, o cliente ainda não está usando o novo DNS.

Critério e limitação: é a única opção que cobre tudo (celulares, TVs, aparelhos de automação, computadores), com nomes à sua escolha. Em troca, você passa a ter um serviço do qual a casa inteira depende: se o Pi-hole cair, ninguém navega. Deixe um DNS secundário configurado no DHCP (o próprio roteador, por exemplo) e inclua o serviço na rotina de manutenção.

Nomes dentro da VPN: MagicDNS do Tailscale

Tudo acima vale para a rede de casa. Fora dela, por uma VPN como a descrita em Acesso remoto seguro, o mDNS não atravessa o túnel e o Pi-hole só responde se o tráfego DNS for encaminhado por ele. O Tailscale resolve isso com o MagicDNS: cada aparelho da sua rede Tailscale ganha um nome fixo, baseado no hostname, resolvido pelo próprio cliente Tailscale em qualquer lugar do mundo. Com ele ativo no painel de administração, ssh maria@servidor ou smb://servidor funcionam no 4G exatamente como em casa, e o nome completo tem a forma servidor.<nome-da-rede>.ts.net. É a maneira mais simples de ter o mesmo nome dentro e fora de casa, ao custo de depender do serviço.

Comparativo e critérios de escolha

Como escolher: para uma casa com notebooks e celulares, mDNS resolve em cinco minutos e sem risco. Se o roteador resolver nomes, melhor ainda, sem fazer nada. Adicione o arquivo hosts nos computadores em que você faz coisas sérias, para não depender da rede. Parta para um DNS local quando TVs e aparelhos de automação precisarem do nome, quando você quiser nomes bonitos para vários serviços (fotos.home.arpa, filmes.home.arpa) ou quando o bloqueio de anúncios já for um objetivo. E ative o MagicDNS no dia em que a VPN entrar em cena.

Quando não confiar em nomes

Nomes são para pessoas. Scripts e tarefas automáticas, principalmente de backup, devem ser mais desconfiados, e por um motivo concreto: a resolução de nome pode falhar de forma temporária e silenciosa. O mDNS não responde enquanto o Wi-Fi reconecta; o Pi-hole está reiniciando às 3h da manhã, justamente quando o backup roda; o cache de um cliente guardou um IP antigo. Em todos esses casos, um programa de backup que usa o nome vai registrar “destino inacessível” e seguir a vida, e você só descobre no dia em que precisa restaurar.

Uma exceção razoável: dentro de uma VPN Tailscale, o endereço 100.x.y.z de cada aparelho é fixo e o MagicDNS é resolvido localmente pelo cliente, o que o torna mais confiável que o mDNS. Ainda assim, para backup, prefira o endereço.

Erros comuns

Marcar este guia como lido (salvo apenas neste navegador)