Une erreur NXDOMAIN ne signifie pas toujours que le DNS de l’appareil ZimaOS est défaillant. Dans ce cas datant de janvier 2026, le ZimaBoard 2 de l’utilisateur fonctionnait normalement sur le réseau local, mais ZimaOS Plus Remote Access ne générait jamais d’URL publique et ZimaClient restait bloqué sur Connexion de l’appareil non prête.
L’utilisateur a réinitialisé l’identifiant réseau, redémarré l’appareil, s’est déconnecté puis reconnecté, et a même testé une version alpha 1.5.4. Aucune de ces étapes n’a rétabli le lien distant natif.
La défaillance concernait le provisionnement distant, pas l’accès local
Le cas présenté comportait trois symptômes liés :
- aucune URL publique
zimaos.linkn’apparaissait sous l’identifiant distant ; - l’ouverture du lien distant attendu renvoyait une erreur NXDOMAIN ;
- ZimaClient restait bloqué dans une boucle de connexion et indiquait que la connexion de l’appareil n’était pas prête.
Pendant ce temps, le ZimaBoard restait accessible via son adresse IP locale et continuait de fournir d’autres services locaux sans rapport.
La mise à jour vers la version alpha 1.5.4 n’a pas résolu le problème
Un membre de la communauté a suggéré de tester une version alpha. L’auteur du message l’a fait, a de nouveau réinitialisé l’identifiant réseau et a reproduit la même défaillance d’accès distant. Il s’agit d’un élément négatif utile : dans ce cas, le simple passage de la version 1.5.3 à cette version alpha n’a pas résolu le provisionnement.
Les anciennes commandes de mise à jour communautaires curl | sh ne sont volontairement pas reprises ici. Elles n’ont pas été publiées par un compte de l’équipe IceWhale dans cette discussion et font référence à des versions historiques.
Le DNS, l’heure, le routage et le protocole HTTPS fonctionnaient correctement
Les résultats des diagnostics ultérieurs étaient particulièrement instructifs. Le ZimaBoard pouvait résoudre les domaines courants, envoyer des requêtes ping vers des adresses IP publiques, utiliser une route par défaut valide, synchroniser l’heure avec NTP et accéder à des points de terminaison HTTPS publics. Aucun service systemd en échec ni aucun blocage évident du pare-feu sortant n’expliquait l’absence de l’URL distante.
Cela réduit considérablement le champ des possibilités. Même si le symptôme observé dans le navigateur était une erreur NXDOMAIN, l’explication générique « votre DNS est défaillant » devient beaucoup moins convaincante.
L’indice le plus probant était la répétition d’erreurs JWT 401
Les journaux de l’utilisateur affichaient à plusieurs reprises des réponses HTTP 401 accompagnées du message invalid or expired jwt, alors que le système tentait de communiquer avec le serveur principal de ZimaOS.
Un intervenant de la communauté a interprété cela comme l’échec de l’authentification auprès du serveur principal ou de l’échange d’enregistrement de l’identifiant distant. Les éléments sont convaincants, mais la discussion ne contient aucune confirmation d’un ingénieur d’IceWhale concernant la cause racine côté serveur. Il convient donc de considérer cette explication comme un diagnostic de la communauté, et non comme une déclaration officielle concernant un incident.
L’utilisateur a mis en place une solution de contournement distincte pour Immich
Comme l’accès distant natif restait indisponible, l’utilisateur a rendu Immich accessible au moyen d’une redirection de port sur le routeur et de DuckDNS. Cela a rétabli l’accès à Immich depuis les navigateurs de la famille, mais n’a pas réparé l’identifiant distant de ZimaOS.
Exposer directement une application sur Internet modifie son modèle de sécurité. Ne reproduisez pas cette solution sans comprendre le TLS, l’authentification, les mises à jour de l’application, les règles du pare-feu et la possibilité que votre FAI fournisse une adresse IP publique joignable.
L’accès distant actuel de ZimaOS utilise le flux de connexion de ZimaClient
La documentation actuelle de ZimaOS décrit l’accès distant comme un canal pair à pair chiffré, configuré via ZimaClient et contrôlé par le paramètre d’accès distant. Si un système actuel ne parvient pas à établir ce canal, comparez l’appareil avec le flux de connexion actuel de l’accès distant avant d’appliquer les conseils de dépannage d’une discussion datant de l’époque de la version 1.5.3.
La version actuelle de ZimaOS considère également l’identifiant réseau comme une information de connexion sensible. Évitez de le publier dans des captures d’écran ou des messages d’assistance.
FAQ sur l’identifiant distant de ZimaOS
L’erreur NXDOMAIN prouve-t-elle que le résolveur DNS local est défaillant ?
Non. Dans le cas présenté, la résolution DNS standard fonctionnait correctement, tandis que l’enregistrement distant de ZimaOS n’avait jamais été publié.
La réinitialisation de l’identifiant réseau a-t-elle résolu le problème ?
Non. L’utilisateur a généré plusieurs nouveaux identifiants sans jamais obtenir d’URL publique.
Quel était l’indice technique le plus probant ?
La répétition de réponses HTTP 401 du serveur principal, signalant un JWT invalide ou expiré, alors que le DNS, l’heure, le routage et la connectivité HTTPS fonctionnaient normalement.
Un problème de JWT côté serveur a-t-il été officiellement confirmé par IceWhale ?
Non. Cette conclusion provenait de l’analyse des journaux de l’utilisateur par la communauté. La discussion publiée ne contenait aucun diagnostic officiel côté serveur.
