Yesterday, a bunch of my integrations broke. Rolling back to an earlier backup didn’t help. It seems to be a DNS issue, but I didn’t make any changes to anything, so a little baffled.
I updated my UniFi after everything broke.
The current broken integrations are Google Drive, Met.no, spotifyplus, and wyzeapi, as well as some I don’t use, but are installed, including esphome, Google Assistant SDK, Music Assistant, and Radio Browser.
My DNS servers are 1.1.1.1 and 8.8.8.8. I’m not quite sure where to start fixing.
I had issues too and it seems the Supervisor was updated, but the DNS plugin update failed.
It seems the update is a bit flaky with the updates of plugins, which might be due to heavy loads on the download site.
Go to the console on your HA server and then do this.
Type “ha supervisor repair” and when it is done do a restart of the system (not just the core).
Type “ha dns info” and see if there are a failed update or updates available and if there is then type “ha dns update”. If it fails, then repeat the command to get it to accept the update.
I’m also now having this problem. I have a ton of info to share to help. Where do I even start?
This started last night (Feb. 17th, 2026 between 12am and 4am) – I had a full auto backup from early morning Feb 16 (4:58am) - which didn’t help. not all integrations are broken. Like the OP, Met.no, radio browser – no longer work. (also nut-ups and some others) – but not all.
Like the OP - dns info reports supervisor “version 2026.02.0”. The main HA console page reports HA Core 2025.8.2, Operating system 15.2 and Frontend 20250811.0
Most notably to demonstrate the issue, Zwave integration connects to 2 instances of zwave-js-ui (full) installs.
One remote over VPN to a raspberry pi (working) and one locally over internal-to-HA network (broken) where the integration can’t connect to the local instance but the add-on pages shows the add-on running and happy.
I have my own internal DNS servers - which properly resolve things like “a0d7b954-zwavejs2mqtt.local.hass.io” - but when in a SSH shell on HA, they do not resolv unless pointing to my general network dns server (192.168.125.2) versus what /etc/resolve.conf points to (172.30.32.3) which results in 172.30.32.3#53 unreachable – even though the main HA console page reports the local address as being 172.30.32.3.
I’ve also restarted and done a ton of things leaving me head-scratching.
OK - I’ve put all my integrations back into place and they’re all working.
I’m not sure what problem the core is having – but there is it.
For anyone else wondering - HA is running on a Vbox VM and my network has a Linux based BIND DNS server while my firewall also has a DMZ VLAN which another Linux based BIND DNS server.
The primary is running Dynamic updates and properly shares to the other secondary server.
And they’re working fine as mentioned doing lookups with the full local.hass.io is needed to see any returns on the stuff coming out of the HA VM.
I added my locals (1.1.1.1 and 8.8.8.8) to servers as you suggested and rebooted and that didn’t seem to help either. I only reloaded the integrations though. Did you reinstall them from scratch?
Otherwise, my ha dns settings are the same, but still no luck. This is not my strong suit - should I be changing things in UniFi?
I had all sorts of backups - but ultimately, I just worked with the most recent version which had everything the way I left it as it broke.
I disabled the broken integrations while I worked to keep things simple – i.e. working on just met.no and zwave-js-ui.
Once I got those working, I just re-enabled all the other broken stuff and they worked (initialized) right away.
Definitely having my own internal DNS server on my network/LAN is a benefit – you may want to consider running one.
I realize that doesn’t answer the question of how something working changed to not-working.
I can say after I had zwave and NUT-ups working again, I could see the histories of when they stopped functioning and it seemed to be the automatic backup that occurred for me Monday morning at 4:57am.
Strangely, I didn’t notice it all day – but I didn’t really look either.
So why it broke is still a mystery to me too.
Can you run a DNS server on your LAN that does mDNS too?
You really can’t roll back here.
If you try then you will install backup and once it starts up it will auto-update the Supervisor, which re-instate the bug.
A manual one from last Friday and another automatic one from early Monday morning.
Neither fixed the problem.
Do you have another Linux box running in your system you could toss a DNS server as a test?
I haven’t tried DNSmasq for mDNS – but for a quick/dirty fix just to see if it works, I’d go there. Setting up BIND takes more work. DNSmasq is a minimal-fuss DNS server.
Also, you could install webmin (not a typo) which is a really nice webGUI for admin’ing DNS A/PTR records… but since mDNS is automagical, that’d be the first step just to see if things work.
It’s like the 2026.02.0 DNS proxy isn’t working right in that it’s not answering for local entries.
The “ha dns” have a few extra options that can be tried, like “ha dns reset” and “ha dns restart”.
There is also a log option.
See all the commands by just typing “ha dns”
