Does it mean, you’ve had the resolv.conf empty? Or, did you add the additional line?
No. It just had the docker dns in. Here is how my resolv.conf looks today, I only added the line with the nameserver 8.8.8.8 manually; the rest was created by docker.
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 8.8.8.8
nameserver 127.0.0.11
options ndots:0
# Based on host file: '/etc/resolv.conf' (internal resolver)
# ExtServers: [8.8.8.8]
# Overrides: [nameservers]
# Option ndots from: internal
This didn’t work for me (still got the errors).
I’ve been trying to roll back to a previous version in the meantime, but can’t seem to get supervisor to roll backwards. Can somebody provide a matching and working set of core, os, and supervisor versions for 2025.04.x? Would be appreciated.
Hi all,
I ran into the same DNS-related issues after upgrading to Home Assistant 2025.5.3 (running in Docker on Debian 12). In the ‘System Information’ it showed that external services like GitHub and the authentication server were unreachable from the HA instance, even though DNS resolution worked from a terminal in the container (through Portainer).
My setup:
- Installation type: Home Assistant Container
- Core version: 2025.5.3
- Docker: true
- Python version: 3.13.3
- OS: Debian 12 (Linux 6.1.0-27-amd64)
- Architecture: x86_64
My fix:
My Docker host used the DNS server of my router (configured to the providers default DNS), which turned out to be unstable for resolving certain domains. The HA container inherited this setting (“Dns”: null).
I disabled “Auto” DNS in my UniFi Cloud Gateway Max WAN settings and manually configured a DNS (1.1.1.1 and 9.9.9.9). After restarting the container, the errors disappeared and everything (including HACS) now works reliably.
My network provider is Odido in the Netherlands. Not sure if this is helpfull, but I thought let me post my solution anyway :).
1 Like
I’ve the similar setup, e.g. docker, chained DNS to provider’s one. As I need to resolve provider local hostnames, I’ve changed just HA resolve.conf, pointing to 8.8.8.8 now, and it works smoothly after that.
1 Like
I wonder why this works for you but doesn’t for me.
Here is my modified /etc/resolv.conf:
/config # cat /etc/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 8.8.8.8
nameserver 192.168.1.1
# Based on host file: '/etc/resolv.conf'
# Overrides: []
/config #
Is there a command I should make after modifying resolv.conf to reload it?
192.168.1.1 is my router.
Adguard Home (on a separate Pi) is my DHCP server & uses quad9 for its upstream DNS servers (none of which was a problem before 2050.5.0).
Edit: Woke up this morning and it is working - perhaps it just took some time to use the new settings?
Turns out I indeed hade an issue with my DNS server. Perhaps it was a coincidence or the timeout used in HA was effectively lowered with the aiodns update.
Due to a large /etc/pihole/pihole-FTL.db (~4GB) the pihole stopped responding for ~10 seconds every full minute. That coincided consistently with the automations in HA.
Interesting. I am not educated enough on networking to know whether I have a similar issue with Adguard Home.
I guess I could switch Adguard Home off and go back to using my internet provider’s router/DCHP server and see what happens.
Here is an easier way to keep it updated whenever you restart HA container.
recreate that file in the same directory as your docker compose.yaml (mine is called ha_resolv.conf)
Add the following to the volumes for homeassistant in your compose.yaml file.
volumes:
- ./ha_resolv.conf:/etc/resolv.conf # workaround for dns issues from 2025.5 on
you will need to rebuild the homeassistant container for it to be loaded the first time.
docker compose up --detach --remove-orphans --build homeassistant
Changing the DNS Server option in my ASUS ZenWiFi AX XT8 router from “Get the DNS IP from your ISP automatically” to Google (8.8.8.8 and 8.8.4.4) stopped the “Timeout while contacting DNS servers” errors.
There is another maybe even easier way in case of using docker-compose.
dns:
- x.x.x.x
- x.x.x.x
No need for additional files!
1 Like
That didn’t work for me. Does it work for you?
We discussed it not working higher up this thread
edit: Gave it another go and it is working for me now - not sure what changed though.
Thank you for this, it is remarkable how many integrations that came back to life and/or became stable again after specifying the DNS server.
1 Like
Adding this to my docker compose indeed solved the problem I was facing with 2 of my integrations, thanks!
I’m seeing the same behavior but not just limited to REST commands (though all of my rests via automations are now failing), spotify, openweathermap, HACS, and several others.
I’m running Pi Hole as well on latest versions. I posted additional info to the issue tracker on github.
I am having the same issue running latest HAOS and latest Pihole versions. This one has been a tricky one to diagnose, not sure if the issue is Home Assistant, Pihole, or my network… 
I have this too occasionaly. Webdav integration startup fails because of this but luckily nothing else is affected at least at the moment.
I also have asus router handling things and run homeassistant in docker.
Just an update from me that I’ve solved my issue. The DNS resolver issues went away after I did one of:
- Ensuring 8.8.8.8 was my primary DNS server across the board (hass.io, router, etc)
- Including 8.8.8.8 and 8.8.4.4 in my /etc/resolv.conf per suggestions in this thread
- Updating hass.io to latest
That didn’t stop it from dropping off my network every day or two.
I discovered the problem with that a was a WPA Group Key Rotation Interval setting on my Asus Router under the Wifi settings that was causing the RasPi to be dropped. Changing that setting resolve my issue.
1 Like
Adding 8.8.8.8 to /etc/resolv.conf did not fix it.
Most of the times it work well, but randomly fails. And in my case it is only during startup when integrations just fail to start because of that (onedrive + webdav).