Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS loop between adguard and hassio_dns #501

Closed
plord12 opened this issue Mar 13, 2024 · 16 comments
Closed

DNS loop between adguard and hassio_dns #501

plord12 opened this issue Mar 13, 2024 · 16 comments
Labels
stale There has not been activity on this issue or PR for quite some time.

Comments

@plord12
Copy link

plord12 commented Mar 13, 2024

Problem/Motivation

With latest hassio_dns adn adguard I see very high cpu usage and then a reboot.

Expected behavior

Low cpu usage + no reboot.

Actual behavior

High cpu usage and then a reboot.

Steps to reproduce

Configure home assistant to use adguard DNS to resolve all queries and reboot.

Proposed changes

See home-assistant/plugin-dns#130 (comment)

The proposed solution to disable "Use private reverse DNS resolvers" avoids the DNS loop.

Perhaps consider disable as the default setting or simply document the possible DNS loop.

@Gunth
Copy link

Gunth commented Mar 13, 2024

I also have the issue with a lot logs like that :

PTR in 2.011455553s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:60700->172.30.32.3:53: i/o timeout
2024/03/13 11:32:51.144585 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;10.0.168.192.in-addr.arpa.	IN	 PTR in 2.050525631s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:40011->172.30.32.3:53: i/o timeout
2024/03/13 11:32:51.144534 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;10.0.168.192.in-addr.arpa.	IN	 PTR in 2.063796849s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:32821->172.30.32.3:53: i/o timeout
2024/03/13 11:32:51.108592 [error] dnsproxy: 172.30.32.3:53: response received over udp: "exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:35352->172.30.32.3:53: i/o timeout"
2024/03/13 11:32:51.144732 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;10.0.168.192.in-addr.arpa.	IN	 PTR in 2.067044979s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:35352->172.30.32.3:53: i/o timeout
2024/03/13 11:32:51.108777 [error] dnsproxy: 172.30.32.3:53: response received over udp: "exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:57226->172.30.32.3:53: i/o timeout"
2024/03/13 11:32:51.144825 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;10.0.168.192.in-addr.arpa.	IN	 PTR in 2.059072529s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:57226->172.30.32.3:53: i/o timeout
2024/03/13 11:32:51.145437 [error] dnsproxy: 172.30.32.3:53: response received over udp: "exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:56831->172.30.32.3:53: i/o timeout"
.......

@jrhbcn
Copy link

jrhbcn commented Mar 13, 2024

I am having the same issue as @Gunth with similar logs:

2024/03/13 16:19:02.815653 [error] dnsproxy: upstream 172.30.32.3:53 failed to exchange ;161.1.168.192.in-addr.arpa. IN PTR in 2.009398542s: exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:40740->172.30.32.3:53: i/o timeout

Running home assistant 2024.3.0, supervisor 2024.03.0 and adguard home addon 5.0.4 with no changes on the configuration and started to suffer this problems overnight. Using a raspberry pi 4 with HAOS 12.0.

Disabling "Use private reverse DNS resolvers" on the adguard configuration seems to solve the issue for me.

@etique57
Copy link

etique57 commented Mar 13, 2024

Similar to me, with slightly different versions :

  • HassOS 11.0
  • Adguard 5.0.3

on a tinkerboard.

Problem suddenly appeared yesterday between 20 and 21pm UTC+1, with no configuration change whatsoever on my side. Did the supervisor upgrade itself, or one of the dockers inside it? No clue.

Doing ha dns reset + ha dns restart (both are required) solves the situation for a few minutes

@jrhbcn
Copy link

jrhbcn commented Mar 13, 2024

@etique57, disabling "Use private reverse DNS resolvers" on the adguard web configuration seems to solve the issue for me as suggested here.

@etique57
Copy link

Thanks @jrhbcn I tried but my trials weren't conclusive.

Actually resolution of names is fine from outside the docker network (my home network or from the SSH addon on Hassio), but I'm using the caddy addon for reverse proxying and that's what fails: all queries from the Caddy addon to the DNS (which one?) fail.

@archerne
Copy link

disabling "Use private reverse DNS resolvers" on the adguard web configuration seems to solve the issue for me

@agners
Copy link
Contributor

agners commented Mar 14, 2024

Problem suddenly appeared yesterday between 20 and 21pm UTC+1, with no configuration change whatsoever on my side. Did the supervisor upgrade itself, or one of the dockers inside it? No clue.

There was a DNS plug-in release (2024.03.0) which upgraded the DNS system to CoreDNS 1.8.7. This is only a patch release though. However, it could be that the patch release slightly altered the behavior when it comes to reverse lookups.

In any case, the setup where the Home Assistant IP where AdGuard add-on runs on is used on DHCP, and "Use private reverse DNS resolvers" is enabled (without an explicit one which is not 172.30.32.3) is (and was!) a broken setup: You point two DNS resolvers against each other. This is bound to fail.

@etique57
Copy link

@agners thanks. not sure if that's still right but this configuration solved the problem for me, at least for now:

  • on the network settings of Hassos:
    image

  • on the AdGuard configuration regarding Private reverse DNS:
    image

@ABoothInTheWild
Copy link

Just wanted to add my voice in support of this issue. My CPU spiked and Home Assistant rebooted every 10 minutes while I debugged this issue over the last couple of hours after updating the addon. I'm running

Core 2024.3.0
HassOS 11.5
Adguard 5.0.4

And the proposed solution to disable "Use private reverse DNS resolvers" worked for me. Thanks for the comments above so far! I was almost about to revert to a backup.

I believe this setting should be disabled by default in the most recent update so current systems don't break for downstream users. The DNS loop should also be documented in case someone wants to enable private reverse DNS resolvers.

@etique57
Copy link

maybe the default private reverse resolver should point to the HAOS IP?

image

@agners
Copy link
Contributor

agners commented Mar 15, 2024

HAOS IP? Why would that be helpful? When AdGuard is installed, the default respnder is AdGuard.. So this would set AdGuard as reverse DNS resolver for AdGuard?

Typically, the device who hands out IP addresses for your network (DHCP server) has a DNS server running which can reverse resolve IP addresses. So this should be your router's IP address.

In most setup, the routers IP is the default DNS server pushed via DHCP. So what might be a good default here is the DNS server of the primary network interface.

@Phoenix-DH
Copy link

Hello together,
I have the same issue with the high CPU load.
I diasbled now the checkbox and the cpu load immediately drops back to normal.

Hopefully the internet connection topic is also solved now.

@Phoenix-DH
Copy link

Does anybode know if the latest version which has just been released fixes the issue? It is 5.0.5.

@Tahutipai
Copy link

You can also resolve this issue by ssh'ing in to your Home Assistant and running:
ha dns options --fallback=false

That fixes it in a cleaner way IMHO.

@agners
Copy link
Contributor

agners commented Apr 4, 2024

Does anybode know if the latest version which has just been released fixes the issue? It is 5.0.5.

It seems not, at least the default config still picks up the DNS plug-in/CoreDNS server:

image

Copy link

github-actions bot commented May 5, 2024

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

@github-actions github-actions bot added the stale There has not been activity on this issue or PR for quite some time. label May 5, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale There has not been activity on this issue or PR for quite some time.
Projects
None yet
Development

No branches or pull requests

9 participants