I probably should have set up an IP Reservation but I hadn’t. I agree that it seems like something that it would have double checked before reassigning though.
1 Like
It looks like this was not the root cause, it stopped again. Sigh
Check the addon logs. I bet it’ll be complaining about not being able to resolve IPs.
Le sigh, it just went down again. Checking the logs as you mentioned:
2024/01/08 20:48:01.311463 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;lb._dns-sd._udp.0.86.168.192.in-addr.arpa. IN PTR in 2.003609584s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:58577->172.30.32.3:53: i/o timeout
I’m reading this as, the upstream DNS @ 172.30.32.3 isn’t available, which after some googling I’m lead to believe is part of the docker network. So I did: docker network ls and started inspecting them. There is one named hassio which, when inspected, lists a container called “hassio_dns” as having that IP address.
I’ve yet to find a next step at this point but am playing around on google. Thought I’d share 
hassio_dns is the internal DNS server container that HA uses. That specific log entry means that it was requested a PTR (pointer) record to resolve a hostname off an IP but no response was received.
172.30.32.3 is the IP of the DNS server container in the docker network and 172.30.32.1 must be the IP of AdGuard.
Update:
So I’ve been playing around inside docker, as you mentioned the hassio_dns is 172.30.32.3 container and 172.30.32.1 is the adguard ip.
The weird thing is, when I run nslookup google.com <HA IP> or even nslookup google.com 172.30.32.1 (because the container IP is also listening according to the AdGuard setup page) both get timeout errors.
However, if I run docker exec addon_a0d7b954_adguard nslookup google.com 172.30.32.3 then it resolves fine. At first I thought this meant that the IP was changing (even though I’ve set up the reservation and the HA IP is static), but I think calling 172.30.32.1 should have circumvented that if that were the issue?
Regardless, This shows that the adguard container is able to talk to hassio_dns fine, so I’m guessing it must be something within the adguard home configuration that’s messing everything up.
Edit:
I guess that means the only thing that’s left that could be failing is whatever communicates between Home Assistant → Adguard Docker container. right?
I have no idea what changed, a new version of AdGuard came out a couple of days ago, I’ve since updated it and now it just…works.
In the setup guide it now says this:
AdGuard Home DNS server is listening on the following addresses:
- 192.168.178.48
- 2001:a61:2a8e:e001:8303:fa33:41a5:c728
- fd00::b447:5d7c:4505:ba0e
- 172.30.32.1
- 127.0.0.1
- ::1
From reading the changelog I can’t figure out what they changed, but it works now.
Mines been not crashing at the very least, but the traffic seems super low and when I try nslookup google.com <ip address> it still times out… so I’m not quite sure how to feel. I wish there were a way to see how many queries were having to go to the DNS backup option on my router but I haven’t found anything natively showing that with Google wifi.
1 Like
I found the problem was the selection of USE PRIVATE REVERSE DNS RESOLVERS which is in the DNS settings. Unchecking that eliminated the errors which I had on two different docker installs.
2 Likes
Yes, I just found the same here, it is enabled on a new install, so filling in the right reverse dns made it work properly.
I updated yesterday homeassistant and everything went to shit. I have no acces to anything. My network only works if I use other DNS (such as google).
And now I’m trying to rollback and HA tells me “‘BackupManager.do_restore_partial’ blocked from execution, no supervisor internet connection”. I already changed HA DNSs.
Turned off reverse dns resolvers, still not working. My whole home went to shit after the HA update…
Any ideas someone?
Did you try after changing the DNS settings both on the web GUI and the HAOS cli, as well as disabling DNS fallback?