An NXDOMAIN error does not always mean the ZimaOS device itself has broken DNS. In this January 2026 case, the user's ZimaBoard 2 worked normally on the local network, but ZimaOS Plus Remote Access never produced a public URL and ZimaClient stayed on Device connection not ready.
The user reset the Network ID, rebooted, signed out and back in, and even tested a 1.5.4 alpha build. None of those steps restored the native remote link.
The Failure Was in Remote Provisioning, Not Local Access
The source case had three linked symptoms:
- no public
zimaos.linkURL appeared under the Remote ID; - opening the expected remote link returned NXDOMAIN;
- ZimaClient remained in a connecting loop and reported that the device connection was not ready.
Meanwhile the ZimaBoard remained reachable by local IP and continued serving unrelated local services.
Updating to 1.5.4 Alpha Did Not Fix It
A community member suggested testing an alpha build. The original poster did so, reset the Network ID again, and reproduced the same remote-access failure. That is useful negative evidence: in this case, simply moving from 1.5.3 to that alpha build did not solve provisioning.
The old community curl | sh update commands are intentionally not repeated here. They were not posted by an IceWhale team account in this thread and refer to historical builds.
Basic DNS, Time, Routing, and HTTPS All Worked
The later diagnostic results were unusually informative. The ZimaBoard could resolve normal domains, ping public IPs, use a valid default route, synchronize time with NTP, and reach public HTTPS endpoints. No failed systemd units or obvious outbound firewall block explained the missing remote URL.
That narrows the problem significantly. It makes a generic “your DNS is broken” explanation much less convincing even though the browser symptom itself was NXDOMAIN.
The Strongest Clue Was Repeated 401 JWT Errors
The user's logs repeatedly showed HTTP 401 responses with an invalid or expired jwt message while the system was trying to communicate with the ZimaOS backend.
A community responder interpreted that as a failed backend authentication or Remote ID registration handshake. The evidence is strong, but the thread does not contain an IceWhale engineer confirming the server-side root cause, so it should remain a community diagnosis rather than an official incident statement.
The User Built a Separate Immich Workaround
Because native Remote Access remained unavailable, the user exposed Immich through router port forwarding and DuckDNS. That restored family browser access to Immich, but it did not repair ZimaOS Remote ID.
Directly exposing an application to the internet changes its security model. Do not copy that workaround without understanding TLS, authentication, application updates, firewall rules, and whether your ISP supplies a reachable public address.
Current ZimaOS Remote Access Uses the ZimaClient Connection Flow
Current ZimaOS describes remote access as an encrypted peer-to-peer channel configured through ZimaClient and controlled by the Remote Access setting. If a current system cannot establish that channel, compare the device with the current Remote Access connection flow before applying troubleshooting from a 1.5.3-era thread.
Current ZimaOS also treats the Network ID as sensitive connection information. Avoid publishing it in screenshots or support posts.
ZimaOS Remote ID FAQ
Does NXDOMAIN prove the local DNS resolver is broken?
No. In this source case, ordinary DNS resolution worked correctly while the ZimaOS remote record itself was never published.
Did resetting the Network ID fix the problem?
No. The user generated new IDs multiple times without getting a public URL.
What was the strongest technical clue?
Repeated backend HTTP 401 responses reporting an invalid or expired JWT while normal DNS, time, routing, and HTTPS connectivity were working.
Was a backend JWT problem officially confirmed by IceWhale?
No. That conclusion came from community analysis of the user's logs. The published thread did not include an official server-side diagnosis.
