Pourquoi un nom d’hôte NAS se résout-il sur certains appareils domestiques mais pas sur d’autres ?
Un nom d’hôte NAS se résout de manière incohérente lorsque les appareils n’utilisent pas la même méthode de nommage, le même résolveur, suffixe ou réponse mise en cache.
Sur un réseau domestique, un ordinateur portable peut trouver nas via le DNS du routeur, un Mac peut trouver nas.local via le DNS multicast, un PC Windows peut revenir à LLMNR ou NetBIOS, et un téléphone peut envoyer la même requête à un DNS privé, un VPN ou un résolveur filtré. Le diagnostic utile consiste donc à comparer le nom exact et le chemin IP sur un appareil fonctionnel et un appareil en échec avant de modifier les paramètres du NAS, du routeur ou de SMB.
Vérifier si l’échec vient de la résolution de nom ou de l’accès au NAS
Testez le NAS par son adresse IP actuelle sur un appareil fonctionnel et un appareil en échec. Testez ensuite séparément le nom d’hôte court, le nom local entièrement qualifié et toute forme .local plutôt que de les traiter comme interchangeables.
Un test de nom d’hôte ajoute une étape de résolution avant que SMB, HTTP ou un autre service puisse se connecter. Le guide ZimaSpace pour vérifier un serveur domestique par nom explique pourquoi l’accès par nom d’hôte ajoute une résolution DNS au chemin que l’accès direct par IP n’exige pas.
Si l’IP fonctionne sur les deux appareils mais qu’un seul résout le nom, concentrez l’investigation sur la couche résolveur. Si l’IP échoue aussi, corrigez d’abord VLAN, isolation Wi-Fi, pare-feu, routage ou accessibilité du service car changer le DNS ne peut pas réparer un chemin réseau bloqué.
Comparer le serveur DNS utilisé par chaque appareil
Notez les serveurs DNS, le type de connexion, la passerelle et le profil réseau actif sur les appareils fonctionnels et en échec. Deux clients sur le même réseau Wi-Fi peuvent utiliser des résolveurs différents à cause de réglages manuels, configuration de nœuds maillés, logiciel VPN, DNS sécurisé du navigateur ou DNS privé mobile.
La résolution de noms locale suit un ordre spécifique au système d’exploitation qui peut combiner mDNS, LLMNR et DNS unicast. Un client qui interroge le routeur peut recevoir un enregistrement local NAS, tandis qu’un client qui interroge un résolveur public reçoit NXDOMAIN car ce nom privé n’existe pas sur Internet public.
Interrogez directement le serveur DNS configuré exact depuis les deux appareils et comparez la réponse, le code de réponse et l’adresse retournée. Si le routeur répond correctement mais que le client en échec ne l’interroge jamais, corrigez la distribution DHCP DNS, l’override client, la politique DNS VPN ou le paramètre DNS chiffré au lieu de modifier le nom d’hôte du NAS.
Séparer les noms d’hôte courts des mDNS et autres solutions locales
Testez nas, le nom local complet du routeur comme nas.home.arpa ou nas.lan, et nas.local comme trois entrées différentes. Le succès avec une forme ne prouve pas que les autres sont configurées.
Les protocoles de secours locaux ne se comportent pas de manière identique selon les systèmes d’exploitation. Une discussion pratique sous Windows montre que désactiver NetBIOS, mDNS ou LLMNR ne force pas automatiquement l’utilisation du DNS pour les noms LAN courts ; le client a toujours besoin d’un enregistrement DNS valide et d’un chemin suffixe.
Si seul nas.local fonctionne, le NAS annonce probablement mDNS mais le routeur ne sert pas un enregistrement DNS local conventionnel. Si seul le nom complet du domaine du routeur fonctionne, ajoutez ou distribuez le suffixe de recherche correct plutôt que de compter sur le secours par nom court.
Vérifier si l’appareil supporte la méthode de découverte utilisée
Laissez le NAS et le routeur inchangés, puis testez le même nom depuis un autre appareil utilisant le même système d’exploitation que le client en échec. Cela permet de distinguer une différence d’implémentation d’appareil d’un problème DNS réseau global.
Les réseaux mixtes réels peuvent montrer exactement cette séparation : un appareil Android peut échouer à résoudre une adresse .local tandis que Windows, iPhone et macOS sur le même LAN réussissent. Un cas documenté décrit un échec de résolution mDNS sous Android malgré la résolution correcte du même hôte par d’autres clients.
Si le symptôme suit un système d’exploitation ou une application, utilisez un enregistrement DNS classique du routeur ou un domaine local entièrement qualifié que tous les clients requis peuvent interroger. Ne concevez pas de montages SMB critiques, chemins de sauvegarde ou rappels autour d’une méthode de découverte supportée seulement par une partie du foyer.
Tester le suffixe de recherche et la requête exacte envoyée par le client en échec
Un nom à un seul label comme nas peut nécessiter un suffixe spécifique à la connexion avant de devenir une requête DNS complète. Comparez la liste des suffixes du client en échec avec celle du client fonctionnel et testez le nom complet directement.
Des utilisateurs OpenWrt ont rapporté des cas où la résolution de noms courts fonctionnait alors que le nom court échouait sur d’autres clients. La différence vient souvent du suffixe ajouté par le système d’exploitation, pas de l’enregistrement NAS lui-même.
Si nas.example.lan fonctionne mais nas échoue, distribuez le même domaine de recherche via DHCP ou enregistrez le nom complet dans les montages SMB et favoris. Évitez de créer plusieurs suffixes non officiels qui se résolvent différemment selon le DNS du routeur, Pi-hole, AdGuard Home et les fichiers hosts des clients.
Effacer l’état client uniquement après que le chemin résolveur est correct
Une fois que les deux appareils utilisent le même résolveur et la même forme de nom, videz le cache DNS du client en échec, déconnectez et reconnectez son profil réseau, puis retestez dans un navigateur ou un shell neuf. Les réponses NXDOMAIN mises en cache peuvent persister malgré la correction côté routeur.
La sélection du résolveur peut aussi dériver quand le système d’exploitation envoie une requête à multicast ou un stub local au lieu du serveur DNS attendu. Un rapport de dépannage Fedora a capturé un client utilisant une résolution locale incohérente alors que la configuration DNS du réseau semblait correcte.
Terminez en faisant en sorte que chaque appareil requis résolve un nom choisi vers l’adresse réservée du NAS, puis confirmez que SMB, le tableau de bord et les applications auto-hébergées se reconnectent via ce nom. Gardez le test IP comme solution de secours diagnostique, mais utilisez un système de nommage documenté plutôt que de dépendre de secours accidentels de protocoles.
Produits recommandés
Assistance et conseils
Plus à lire
Une galerie auto-hébergée peut-elle préserver l’association des Live Photos Apple ?
Une décision conditionnelle concernant un serveur personnel pour l’association des Live Photos Apple, avec des tests contrôlés, l’interprétation des résultats, une procédure de retour...
Pouvez-vous importer Google Takeout et les sauvegardes de téléphone dans une seule photothèque ?
Une décision conditionnelle concernant un serveur domestique pour l’importation groupée de photos, avec des tests contrôlés, l’interprétation des résultats, un retour en arrière et...
Immich peut-il utiliser une bibliothèque externe sans prendre possession des fichiers ?
Une décision conditionnelle pour serveur personnel concernant la propriété des bibliothèques externes d’Immich, avec des tests contrôlés, l’interprétation des résultats, un retour en arrière...
