Een NXDOMAIN-fout betekent niet altijd dat de DNS van het ZimaOS-apparaat zelf defect is. In deze casus uit januari 2026 werkte de ZimaBoard 2 van de gebruiker normaal op het lokale netwerk, maar genereerde ZimaOS Plus Remote Access nooit een openbare URL en bleef ZimaClient hangen op Apparaatverbinding niet gereed.
De gebruiker reset het netwerk-ID, startte het apparaat opnieuw op, meldde zich af en weer aan en testte zelfs een alphaversie 1.5.4. Geen van deze stappen herstelde de native externe verbinding.
De fout zat in het op afstand instellen, niet in de lokale toegang
De oorspronkelijke casus had drie samenhangende symptomen:
- er verscheen geen openbare
zimaos.link-URL onder het externe ID; - het openen van de verwachte externe link gaf NXDOMAIN terug;
- ZimaClient bleef in een verbindingslus hangen en meldde dat de apparaatverbinding niet gereed was.
Ondertussen bleef de ZimaBoard bereikbaar via het lokale IP-adres en bleef deze andere lokale diensten aanbieden.
Bijwerken naar 1.5.4 Alpha loste het probleem niet op
Een communitylid stelde voor een alphaversie te testen. De oorspronkelijke poster deed dat, reset het netwerk-ID opnieuw en reproduceerde dezelfde fout bij externe toegang. Dat is nuttig negatief bewijs: in deze casus loste simpelweg de overstap van 1.5.3 naar die alphaversie het instellen van de verbinding niet op.
De oude community-updateopdrachten met curl | sh worden hier bewust niet herhaald. Ze waren in deze thread niet geplaatst door een IceWhale-teamaccount en verwijzen naar historische builds.
Basis-DNS, tijd, routering en HTTPS werkten allemaal
De latere diagnostische resultaten waren bijzonder informatief. De ZimaBoard kon normale domeinen omzetten, openbare IP-adressen pingen, een geldige standaardroute gebruiken, de tijd synchroniseren met NTP en openbare HTTPS-eindpunten bereiken. Geen mislukte systemd-eenheden of duidelijke blokkade van uitgaand verkeer verklaarde de ontbrekende externe URL.
Dat beperkt het probleem aanzienlijk. Hoewel het browsersymptoom zelf NXDOMAIN was, wordt een algemene verklaring als “je DNS werkt niet” hierdoor veel minder aannemelijk.
De sterkste aanwijzing waren herhaalde 401-fouten met JWT
In de logboeken van de gebruiker verschenen herhaaldelijk HTTP 401-antwoorden met de melding invalid or expired jwt terwijl het systeem probeerde te communiceren met de ZimaOS-backend.
Een communityreageerder interpreteerde dit als een mislukte authenticatie bij de backend of een mislukte registratiehandshake van het externe ID. Het bewijs is sterk, maar de thread bevat geen bevestiging van een IceWhale-engineer van de oorzaak aan serverzijde. Daarom moet dit een communitydiagnose blijven en geen officiële incidentverklaring.
De gebruiker bouwde een afzonderlijke workaround voor Immich
Omdat Remote Access niet beschikbaar bleef, stelde de gebruiker Immich beschikbaar via port forwarding op de router en DuckDNS. Daarmee kregen gezinsleden weer toegang tot Immich via de browser, maar ZimaOS Remote ID werd er niet door hersteld.
Een toepassing rechtstreeks aan internet blootstellen verandert het beveiligingsmodel. Neem deze workaround niet over zonder inzicht in TLS, authenticatie, updates van de toepassing, firewallregels en de vraag of je internetprovider een bereikbaar openbaar adres levert.
De huidige externe toegang van ZimaOS gebruikt de verbindingsstroom van ZimaClient
Het huidige ZimaOS beschrijft externe toegang als een versleuteld peer-to-peer-kanaal dat via ZimaClient wordt geconfigureerd en door de instelling Remote Access wordt beheerd. Als een actueel systeem dit kanaal niet tot stand kan brengen, vergelijk het apparaat dan met de huidige verbindingsstroom voor Remote Access voordat je probleemoplossing uit een thread uit de periode van 1.5.3 toepast.
Het huidige ZimaOS beschouwt het netwerk-ID bovendien als gevoelige verbindingsinformatie. Publiceer dit niet in schermafbeeldingen of supportberichten.
Veelgestelde vragen over ZimaOS Remote ID
Bewijst NXDOMAIN dat de lokale DNS-resolver defect is?
Nee. In deze broncasus werkte de normale DNS-resolutie correct, terwijl het externe record van ZimaOS zelf nooit was gepubliceerd.
Loste het resetten van het netwerk-ID het probleem op?
Nee. De gebruiker genereerde meerdere keren nieuwe ID's zonder een openbare URL te krijgen.
Wat was de sterkste technische aanwijzing?
Herhaalde HTTP 401-antwoorden van de backend met de melding dat de JWT ongeldig of verlopen was, terwijl normale DNS-, tijd-, routerings- en HTTPS-connectiviteit wel werkte.
Is een JWT-probleem bij de backend officieel bevestigd door IceWhale?
Nee. Die conclusie kwam voort uit een communityanalyse van de logboeken van de gebruiker. De gepubliceerde thread bevatte geen officiële diagnose van het probleem aan serverzijde.
