FYI: Forcing DNS to 8.8.8.8 (via docker compose’s dns attribute) immediately fixed it for me.
I am not sure if mine was the same cause as others, but it turns out my Pihole was lowkey getting DOSed by my usual traffic - too many queries per second so it was dropping some. I reduced the queries (by switching things like Loki and Zabbix to IP not domain name) and it resolved the timeouts in logs I was seeing.
I know it’s been a few months, but I’ve been having this issue for many months as well and haven’t been able to find the source of the problem.
I run HA on docker on a Proxmox LXC
I have two copies of pihole running, one as a primary and one for failover/backup, both in LXCs but not in docker.
All of my timeouts are obtaining local IP addresses for home network components, so adding 8.8.8.8 will do nothing for me.
Looking in pihole I see HA talking to both of my DNS servers, so it obviously has timeouts on one of them and fails over to the next…perhaps the drop outs I’m getting is when it periodically fails getting a reply from that second server as well.
I’ve written all sorts of monitoring tools on many machines to see if they see any lack of DNS resolution, and none of them seem to experience the problem, I get zero dropouts from any other services or applications on the network, only from HA.
I mostly see the issue on rest APIs to a local invtertor on my network, and when calling uptimerobot APIs. Though I am not sure that last one is DNS or not.
My logs can be filled with the following message sometimes.
Error fetching data: http://xxxxx.xxxxx.xx/ failed with Cannot connect to host xxxxx.xxxxx.xx:80 ssl:default [Timeout while contacting DNS servers]
I’m experiencing the same issue for a few months now. Running HA on HAOS.
I’ve tried my router’s DNS, my own AdGuard, 8.8.8.8, nothing helps.
Sharing that this proposed fix worked perfectly for the “Timeout while contacting DNS servers” error that I had been getting, which I noticed while trying to use HACS to download or update plugins. So thanks for that!
Here’s my setup:
- Home Assistant (Docker) Container
- Core version: 2025.12.3
- Python: 3.13.9
- OS: Debian GNU/Linux 11 (bullseye)
- Architecture: aarch64
- Pi-hole + Tailscale also installed
What I had noticed was that in my Home Assistant container the file /etc/resolv.conf looked like this:
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 100.100.100.100
search <tailscale-magic-dns>.ts.net
# Based on host file: '/etc/resolv.conf'
# Overrides: []
I’m running HA with host networking, therefore if I understand it correctly using the Docker dns: options wouldn’t fix my problem; so, since I won’t be needing Tailscale’s Magic DNS feature in Home Assistant, I created a custom resolv.conf file:
sudo mkdir -p /opt/ha-dns
sudo vi /opt/ha-dns/resolv.conf
With this content:
nameserver 127.0.0.1 # Pi-hole
options timeout:1 attempts:3
I edited my Home Assistant Docker compose file in order to add the mount of a custom resolv.conf file:
volumes:
...
- /opt/ha-dns/resolv.conf:/etc/resolv.conf:ro
And restarted the container.
After HA was once again online, I verified in Pi-hole that queries using DNS (such as a reload of the HACS integration) were showing up correctly, e.g.:
And the “Timeout while contacting DNS servers” error disappeared; therefore, I am once again able to use HACS.
Those don’t fix the issue i have.
I use Docker container name to point to other services that are HAss integrations.
HAss used to be able to reach them through the container name.
HAss can’t reach them through the container name now.
Using an external resolver doesn’t fix the issue, as the external resolver doesn’t have the container names.
I therefore assigned static IPs to my containers and declared the IPs instead of the names.
This problem has been going on since 25.5 here too but I have sort of lived with it filling the log book on a daily basis. Mostly the system does seem to work, but a couple of more intensive integrations do suffer. Energy Consumption and HVAC specifically.
Can any of the solutions be employed on a native HAOS hass instance like I am running? I can’t really get access to some of the files mentioned ( or I don’t yet know how to do so ).
I also can’t understand why this is not a CORE DEV BUG which is urgently worked and resolved? DNS is so fundamental. Is it something specific with all the users posting in this topic then? [Just speculating].
I also can’t understand why this is not a CORE DEV BUG which is urgently worked and resolved?
I raised the issue on Github back in May, but that is no guarantee that the devs will look at it.
Ok - I created another more lengthy bug I expect they are related.
I am getting these too - noticed it since 2026.2 for some reason. And it effects almost all plugins requesting external data.
Commented to @Toness Github issue to bring this to attention? ;-).
By the way, i am running my HA on a Pi4 at HAOS.
I’ve used the site a few times to compare latency and reliability, and it helped me figure out which servers were actually stable over weeks, not just on paper. If you’re checking options in the US, the usa dns server list made it easy to spot high‑trust picks with solid uptime, so I didn’t have to trial-and-error everything myself.
I also have this issue.
My hardware setup:
- Unify Network 192.168.178.0/23
- Home Assistant running direct via HAOS (HA.2026.4.4)
- 2nd HA as Testsystem running on a Proxmox Container (HA.2026.5)
- 2 x Technitium Upstream DNS - via VIP (as Fallover via keepalived) both on different Proxmox
- 2 x Pi-Hole - via VIP (as Fallover via keepalived) - Master Pi-Hole is a Raspberry Pi, Backup Pi-Hole is running on Proxmox
IP assignment:
- Titanium VIP: 192.168.178.8
- Titanium Master: 192.168.179.191
- Titanium Backup: 192.168.179.9
- Pi-Hole VIP: 192.168.178.9
- Pi-Hole Master: 192.168.178.128
- Pi-Hole Backup: 192.168.178.13
1. Normal Setup: (in theory ideal)
HA --> Pi-Hole VIP --> Pi-Hole (normally Master) --> Titanium VIP --> Titanium (normally Master)
--> With this setup I had a lot of timeout errors
2. Better Setup:
HA --> Pi-Hole VIP --> Pi-Hole (normally Master) --> Titanium Master
--> Titanium Backup
dnsmac on the Pi-Hole in:
/etc/dnsmasq.d/99-allservers.conf
is set to:
all-servers
to ensure that both upstream DNS are used in parallel
--> With this setup it was better that in the normal setup
3. Current Setup for testing:
HA --> Pi-Hole VIP --> Pi-Hole (normally Master) --> Titanium Master
--> Titanium Backup
HA --> direct without Pi-Hole --> Titanium VIP
I know this setup looks a bit crazy.
The plan was to only change the via the router distributed Pi-Hole VIP to the Titanium VIP but HA does not allow to only change the DNS server if you are using dynamic network config (HA gets a fixed IP via the DHCP Server) You can only add an additional DNS.
➜ ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.178.8
- dns://192.168.178.9
mdns: true
servers: []
update_available: false
version: 2026.02.0
version_latest: 2026.02.0
--> With this setup its much better than with the both setups above.
Maybe its an issue with the HA and Pi-Hole combination.
During my tests (with the 1. option) I also observed Stale DNS answers. Normally this should not be a problem, afaik. But I was not able to reproduce this again.
4. Next Option
now the next step could be to change the network config inside HA to static so that I can check direct with (only) the tianium upstream DNS.
After further testing using the direct IP of the Technitium server 1, I observed no outages throughout the day. This strongly suggests that the underlying issue has likely been identified.
The root cause appears to have been an incorrect VRRP configuration: I had effectively set up two separate VIP “clusters” (two Pi-hole nodes and two Technitium nodes), but both shared the same VRID. This caused unintended overlap between the VRRP domains.
The issue only became visible through log entries showing “invalid password” messages, which indicated that VRRP advertisements were being received from a mismatched or conflicting configuration.
Separating the VRIDs for the two environments resolved the conflict and restored stable DNS behaviour.
I no longer need to do this as it has been working for me again since 2026.5. It has probably been working earlier than that, but it was drawn to my attention (over on reddit another user reported it was working again) and so I tried it myself.
How about you?
I was having the same issues but running a docker container, no pi-hole just a standard ISP provided router (Fritzbox). I confirmed that there were no DNS delays from using either the local router as the DNS server or google/cloudfare servers.
I eventual discovered that the default setting in a docker container is to use a docker provided dns server. You can check yours by getting a shell up under the container running HA and then checking /etc/resolve.conf, mine was set to 127.0.0.x i.e. the docker DNS server. I changed my docker container configuration to directly use a DNS server. Under docker compose it is
DNS:
- 8.8.8.8
- 1.1.1.1 etc
This has solved the problem. I can only assume that HA has tightened the timeouts (or one of the packages) which has caused this as it has been running fine for 3 years under the old config.
Not sure if you are replying to myself or @Mindreader but we have the same setup (docker, no Pi-Hole/Adguard Home...) and was using dns: in compose.yaml as my workaround per @homer-assist's suggestion.
...but this has not been necessary for me since I rechecked it with 2026.5
The other interesting thing though is that I run 2 HA instances (identical hardware etc but different locations) and the other one never exhibited this issue at all.