Perché un nome host NAS si risolve su alcuni dispositivi domestici ma non su altri?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Un hostname NAS si risolve in modo incoerente quando i dispositivi non utilizzano lo stesso metodo di denominazione, resolver, suffisso o risposta memorizzata nella cache.

In una rete domestica, un laptop può trovare nas tramite il DNS del router, un Mac può trovare nas.local tramite multicast DNS, un PC Windows può ricorrere a LLMNR o NetBIOS, e un telefono può inviare la stessa ricerca a Private DNS, a una VPN o a un resolver filtrato. La diagnosi utile è quindi confrontare il nome esatto e il percorso IP su un dispositivo funzionante e uno non funzionante prima di modificare le impostazioni del NAS, del router o di SMB.

Verificare se il problema è la risoluzione del nome o l’accesso al NAS

Testa il NAS tramite il suo indirizzo IP attuale sia su un dispositivo funzionante che su uno non funzionante. Poi testa separatamente il nome host breve, il nome locale completamente qualificato e qualsiasi forma .local invece di considerarli intercambiabili.

Un test del nome host aggiunge un passaggio di risoluzione prima che SMB, HTTP o un altro servizio possano connettersi. La guida di ZimaSpace per controllare un server domestico tramite nome spiega perché l’accesso tramite hostname aggiunge la risoluzione DNS al percorso che l’accesso diretto tramite IP non richiede.

Se l’IP funziona su entrambi i dispositivi ma solo uno risolve il nome, mantieni l’indagine a livello di resolver. Se anche l’IP fallisce, risolvi prima VLAN, isolamento Wi-Fi, firewall, routing o raggiungibilità del servizio perché modificare il DNS non può riparare un percorso di rete bloccato.

Confronta il server DNS usato da ciascun dispositivo

Annota i server DNS, il tipo di connessione, il gateway e il profilo di rete attivo sui dispositivi funzionante e non funzionante. Due client con lo stesso nome Wi-Fi possono comunque usare resolver diversi a causa di impostazioni manuali, configurazione di nodi mesh, software VPN, DNS sicuro del browser o Private DNS mobile.

La risoluzione dei nomi locali segue un ordine specifico del sistema operativo che può combinare mDNS, LLMNR e DNS unicast. Un client che interroga il router può ricevere un record NAS locale, mentre un client che interroga un resolver pubblico riceve NXDOMAIN perché quel nome host privato non esiste su internet pubblico.

Interroga direttamente il server DNS configurato esatto da entrambi i dispositivi e confronta la risposta, il codice di risposta e l’indirizzo restituito. Se il router risponde correttamente ma il client non funzionante non lo interroga mai, correggi la distribuzione DHCP DNS, l’override client, la politica DNS della VPN o l’impostazione DNS crittografato invece di modificare l’hostname del NAS.

Separa gli hostname brevi da mDNS e altri fallback locali

Testa nas, il nome locale completo del router come nas.home.arpa o nas.lan, e nas.local come tre input distinti. Il successo con una forma non prova che le altre siano configurate.

I protocolli di fallback locali non si comportano allo stesso modo su tutti i sistemi operativi. Una discussione pratica su Windows mostra che disabilitare NetBIOS, mDNS o LLMNR non fa automaticamente sì che i nomi LAN brevi usino il DNS; il client ha comunque bisogno di un record DNS valido e di un percorso suffisso.

Se funziona solo nas.local, probabilmente il NAS pubblicizza mDNS ma il router non serve un record DNS locale convenzionale. Se funziona solo il nome completo del dominio del router, aggiungi o distribuisci il suffisso di ricerca corretto invece di affidarti al fallback del nome breve.

Verifica se il dispositivo supporta il metodo di scoperta che stai usando

Lascia invariati NAS e router, poi testa lo stesso nome da un altro dispositivo con lo stesso sistema operativo del client non funzionante. Questo separa una differenza di implementazione del dispositivo da un problema DNS a livello di rete.

Le reti miste reali possono mostrare esattamente questa divisione: un dispositivo Android può non risolvere un indirizzo .local mentre dispositivi Windows, iPhone e macOS sulla stessa LAN riescono. Un caso documentato descrive un fallimento di risoluzione mDNS su Android nonostante altri client risolvano lo stesso host.

Se il sintomo riguarda un solo sistema operativo o app, usa un record DNS convenzionale del router o un dominio locale completamente qualificato che tutti i client necessari possano interrogare. Non progettare mount SMB critici, percorsi di backup o callback basandoti su un metodo di scoperta supportato solo da parte della famiglia.

Testa il suffisso di ricerca e la query esatta inviata dal client non funzionante

Un nome a singola etichetta come nas può necessitare di un suffisso specifico della connessione prima di diventare una query DNS completa. Confronta la lista dei suffissi del dispositivo non funzionante con quella del dispositivo funzionante e testa direttamente il nome completo.

Utenti OpenWrt hanno segnalato casi in cui la risoluzione di hostname brevi funziona su altri client ma non sul dispositivo in questione. La differenza è spesso il suffisso che il sistema operativo aggiunge, non il record NAS stesso.

Se nas.example.lan funziona ma nas no, distribuisci lo stesso dominio di ricerca tramite DHCP o salva il nome completo nei mount SMB e nei segnalibri. Evita di creare più suffissi non ufficiali che si risolvono in modo diverso tra DNS del router, Pi-hole, AdGuard Home e file hosts dei client.

Pulisci lo stato del client solo dopo che il percorso del resolver è corretto

Una volta che entrambi i dispositivi usano lo stesso resolver e la stessa forma di nome, svuota la cache DNS del client non funzionante, disconnetti e riconnetti il suo profilo di rete, e ritesta in un browser o shell puliti. Le risposte NXDOMAIN memorizzate nella cache possono persistere anche dopo la correzione lato router.

La selezione del resolver può anche variare quando il sistema operativo invia una ricerca a multicast o a uno stub locale invece che al server DNS previsto. Un report di troubleshooting Fedora ha catturato un client che usava una risoluzione locale incoerente anche se la configurazione DNS della rete sembrava corretta.

Concludi facendo in modo che ogni dispositivo richiesto risolva un nome scelto all’indirizzo riservato del NAS, quindi conferma che SMB, la dashboard e le app self-hosted si riconnettano tramite quel nome. Mantieni il test IP come fallback diagnostico, ma usa un sistema di denominazione documentato invece di dipendere da fallback accidentali di protocollo.

Supporto e consigli

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.