Blocked WAN = Query Clean-Up Lag/Delay

[ghost]

If I block WAN connection entrely, the function of cleaning AdGuard Home queries/stats becomes unresponsive for a period of time and several attempts are required to clean up queries/stats. This happens on every Raspberry Pi I have.

There doesn't appear to be a way to clean up Optimistic Cache. If I temporarily disable it and/or temporarily use "Disable Protection", the use of cached DNS queries remains. There should be functions similar to:

sudo ip -s -s neigh flush all
sudo killall -HUP dnsmasq
sudo ip route flush cache

[fernvenue]

For me, everytime when I disable Optimistic Cache and enable it again, the cache will gone. Or maybe you can try fully restart AdGuardHome, that's quite simple.

And that Block WAN thing, we need more information, at leaset you should tell us how you block your WAN connection. I strongly believe that your network reconfiguration caused your connection to AdGuardHome to have to be reconnected, reconnecting will of course take time.

[agneevX]

the function of cleaning AdGuard Home queries/stats becomes unresponsive for a period of time and several attempts are required to clean up queries/stats.

What exact "function" are you referring to here, that happens to get unresponsive? Because queries or statistics are not "cleaned up".

If I temporarily disable it and/or temporarily use "Disable Protection", the use of cached DNS queries remains.

Any option that causes dnsproxy to restart, flushes the cache ie. saving most settings in DNS settings.

[ainar-g]

I addition to the other questions, please add AdGuard Home version to the original issue. Also, what kind of upstreams do you use? We've had some issues with DoH upstreams behaving badly during reconnections in the past, but that has been fixed a long time ago.

[ghost]

I use the latest AdGuard Home (Edge). To summarize, AdGuard Home becomes unresponsive for common tasks, such as saving changed settings, cleaning stats and queries, when it is not able to reach static.adguard.com due to whatever reason. AdGuard Home displays a network error in lower right corner when that happens. There is an obvious 10-15 seconds delay before tasks (performed during the time AdGuard Home is disconnected from static.adguard.com) apply.

I think static.adguard.com is used verify AdGuard Home version and update it. The "sudo ./AdGuardHome --no-check-update" command is supposed to stop self-update behavior, but it doesn't appear to do so.

It would be great if there was an official way to block static.adguard.com or force AdGuard Home to connect to that domain only if user decides to check for updates without causing unresponsive behavior I mention above.

The static.adguard.com domain is never listed up in AdGuard Home queries. I can understand why, but having personal/private local DNS server is at least partially about control over DNS queries and as such, all queries should be listed, including static.adguard.com.

[ainar-g]

We've located the bug, and we'll try to fix it in the next few days. Thanks for the info!

The "sudo ./AdGuardHome --no-check-update" command is supposed to stop self-update behavior, but it doesn't appear to do so.

It's not a command, but rather a flag that you can provide to the AdGuardHome invocation. You haven't mentioned how you installed and how you start AdGuard Home, but generally you can add that option to the service / unit file and reload the daemon configuration.

The static.adguard.com domain is never listed up in AdGuard Home queries. I can understand why, but having personal/private local DNS server is at least partially about control over DNS queries and as such, all queries should be listed, including static.adguard.com.

There were a few discussions regarding that, and I think that the last time we've had them, the consensus was that those queries are fairly uncommon and are also queries for well known domains, so adding them to the query log would be a lot of work without too much pay off. You can open a new issue about that feature, and if enough people support it, we'll implement it.

[ainar-g]

@OpenSourceGhost, we've just released v0.108.0-a.117+0a1ff65b to the edge channel. Could you please check if that fixes the issue for you?

[ghost]

Yes! Thank you!