Um nome de host NAS resolve-se de forma inconsistente quando os dispositivos não utilizam o mesmo método de nomeação, resolvedor, sufixo ou resposta em cache.
Numa rede doméstica, um portátil pode encontrar nas através do DNS do router, um Mac pode encontrar nas.local através do DNS multicast, um PC Windows pode recorrer ao LLMNR ou NetBIOS, e um telemóvel pode enviar a mesma consulta para DNS Privado, uma VPN ou um resolvedor filtrado. O diagnóstico útil é, portanto, comparar o nome exato e o caminho IP num dispositivo que funciona e num que falha antes de alterar as definições do NAS, router ou SMB.
Comprove se a Falha é na Resolução do Nome ou no Acesso ao NAS
Teste o NAS pelo seu endereço IP atual tanto num dispositivo que funciona como num que falha. Depois teste o nome curto, o nome local totalmente qualificado e qualquer forma .local separadamente, em vez de os tratar como intercambiáveis.
Um teste de nome de host adiciona uma etapa de resolução antes de o SMB, HTTP ou outro serviço poderem conectar. O guia da ZimaSpace para verificar um servidor doméstico por nome explica por que o acesso por nome de host adiciona resolução DNS ao caminho que o acesso direto por IP não requer.
Se o IP funcionar em ambos os dispositivos mas apenas um resolver o nome, mantenha a investigação na camada do resolvedor. Se o IP também falhar, corrija primeiro VLAN, isolamento Wi-Fi, firewall, encaminhamento ou acessibilidade do serviço, porque alterar o DNS não pode reparar um caminho de rede bloqueado.
Compare o Servidor DNS Usado por Cada Dispositivo
Registe os servidores DNS, tipo de ligação, gateway e perfil de rede ativo nos dispositivos que funcionam e que falham. Dois clientes na mesma rede Wi-Fi podem ainda usar resolvedores diferentes devido a definições manuais, configuração de nós mesh, software VPN, DNS seguro do navegador ou DNS Privado móvel.
A resolução de nomes locais segue uma ordem específica do sistema operativo que pode combinar mDNS, LLMNR e DNS unicast. Um cliente que pergunta ao router pode receber um registo local do NAS, enquanto um cliente que pergunta a um resolvedor público recebe NXDOMAIN porque esse nome privado não existe na internet pública.
Consulte diretamente o servidor DNS configurado em ambos os dispositivos e compare a resposta, código de resposta e endereço retornado. Se o router responder corretamente mas o cliente que falha nunca o questionar, corrija a distribuição DHCP DNS, a substituição do cliente, a política DNS da VPN ou a configuração de DNS encriptado em vez de editar o nome do NAS.
Separe Nomes Curtos de Host de mDNS e Outras Alternativas Locais
Teste nas, o nome local completo do router como nas.home.arpa ou nas.lan, e nas.local como três entradas diferentes. O sucesso com uma forma não prova que as outras estão configuradas.
Os protocolos de fallback locais não se comportam de forma idêntica em todos os sistemas operativos. Uma discussão prática sobre Windows mostra que desativar NetBIOS, mDNS ou LLMNR não faz automaticamente com que nomes LAN curtos usem DNS; o cliente ainda precisa de um registo DNS válido e caminho de sufixo.
Se apenas nas.local funcionar, o NAS provavelmente está a anunciar mDNS mas o router não está a servir um registo DNS local convencional. Se apenas o nome completo do domínio do router funcionar, adicione ou distribua o sufixo de pesquisa correto em vez de depender do fallback de nome curto.
Verifique se o Dispositivo Suporta o Método de Descoberta que Está a Usar
Mantenha o NAS e o router inalterados, depois teste o mesmo nome a partir de outro dispositivo com o mesmo sistema operativo do cliente que falha. Isto separa uma diferença de implementação do dispositivo de um problema DNS em toda a rede.
Redes reais com dispositivos mistos podem mostrar exatamente esta divisão: um dispositivo Android pode falhar ao resolver um endereço .local enquanto dispositivos Windows, iPhone e macOS na mesma LAN têm sucesso. Um caso documentado descreve falha de resolução mDNS no Android apesar de outros clientes resolverem o mesmo host.
Se o sintoma seguir um sistema operativo ou aplicação, use um registo DNS convencional do router ou um domínio local totalmente qualificado que todos os clientes necessários possam consultar. Não projete montagens SMB críticas, caminhos de backup ou callbacks em torno de um método de descoberta que só parte da casa suporta.
Teste o Sufixo de Pesquisa e a Consulta Exata Enviada pelo Cliente que Falha
Um nome de etiqueta única como nas pode precisar de um sufixo específico da ligação antes de se tornar uma consulta DNS completa. Compare a lista de sufixos do dispositivo que falha com o do dispositivo que funciona e teste o nome completo diretamente.
Utilizadores OpenWrt relataram casos onde a resolução de nomes curtos falha enquanto o nome curto funciona noutros clientes. A diferença é frequentemente o sufixo que o sistema operativo acrescenta, não o registo do NAS em si.
Se nas.example.lan funcionar mas nas falhar, distribua o mesmo domínio de pesquisa via DHCP ou guarde o nome completo em montagens SMB e favoritos. Evite criar vários sufixos não oficiais que resolvem de forma diferente no DNS do router, Pi-hole, AdGuard Home e ficheiros hosts dos clientes.
Limpe o Estado do Cliente Apenas Depois de o Caminho do Resolvedor Estar Correto
Uma vez que ambos os dispositivos usem o mesmo resolvedor e forma de nome, limpe a cache DNS do cliente que falha, desligue e volte a ligar o seu perfil de rede, e teste novamente num navegador ou shell limpo. Respostas NXDOMAIN em cache podem persistir para além da correção no lado do router.
A seleção do resolvedor também pode variar quando o sistema operativo envia uma consulta para multicast ou um stub local em vez do servidor DNS esperado. Um relatório de resolução de problemas Fedora capturou um cliente a usar resolução local inconsistente apesar da configuração DNS da rede parecer correta.
Termine fazendo com que todos os dispositivos necessários resolvam um nome escolhido para o endereço reservado do NAS, depois confirme que SMB, o painel de controlo e as aplicações auto-hospedadas se reconectam através desse nome. Mantenha o teste de IP como fallback diagnóstico, mas use um sistema de nomeação documentado em vez de depender de fallbacks acidentais de protocolo.
Suporte e Dicas
Mais para Ler

Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...

Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...

Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um diagnóstico da perda de sessão que abrange o âmbito do reinício, a propriedade dos cookies, a rotação de segredos, as sessões suportadas por...

