that is another option but then you have to weigh the decompression time/power vs space. Neither is that much of an issue for rpi4 but for smaller dual or single core routers its a consideration. Also you have enough space so you don't have to compress it.
1 Like
Oh btw I received adguardhome 0.107.6-1 » 0.107.18-1 opkg update. I might try it later since I'm busy at work. Also I haven't received flood of Unpacking udp packet: dns: bad rdata erros for days only npacking udp packet: dns: buffer size too small
1 Like
First of all thank you for this great tutorial. I have a problem and I must be doing it wrong. I have adguardhome installed in docker on my NAS (1.15) and I have my router openwrt (1.1).
I want adguardhome to be the primary DNS server and not do DHCP and I want the router to be the secondary DNS and to be the only DHCP server on the network. So I end up with two IP addresses instead of just one.
The idea is that if Adguardhome is not available that I can browse the internet only with my router.
With the configuration below the name resolution with does not work.
If I understood correctly, the router uses port 54 and the NAS uses port 53.
My /opt/AdGuardhome.yaml file:
dns:
bind_hosts:
- 127.0.0.1
- ::1
- 192.168.1.15
- fd1a:c860:7174::1
port: 53
resolve_clients: true
use_private_ptr_resolvers: true
local_ptr_upstreams:
- 192.168.1.1:54
Can you help me correct my configuration please in relation to the operation I am looking for?
I can provide you with more information if needed.
one last thing. In the dashboard in the top client box, I only have my router that appears. I had managed to configure it so that we could each client separately.
Thanks very much.
Firstly you cannot use these instructions to do a setup like yours. These instructions are for installing on router.
You won't need my scripts or to do major changes on your router. The only thing you will need to do is set your DHCP server to broadcast to use AGH DNS on your NAS. (option 6 is what you need)
This also means you won't need to move dnsmasq and so it will be port 53 on your router and not port 54.
Is there any reason why you can't run AGH on your router? or just easier to run it on your NAS?
Regarding dual DNS? That will not work. Having AGH as primary DNS and a secondary that is completely unfiltered gives a bypass. Its the equivalent of having a guard post that has a tunnel under it that anyone can use. You could mitigate this however by using AGH as your primary and another filtered DNS as secondary but again isn't ideal unless they both act similarly with regard to filters/blocking.
It seems very clear.
My router is a xiaomi Mi 3G V1 which is barely powerful enough to run AGH. AGH's administration interface was slow and I was limited in the number of filters because they slowed everything down. I tested the installation on my NAS and it was perfect, without power or memory limits.
I'm going to forget about this double DNS plan and I'm going to follow your configuration recommendations. Thanks again for your very quick and detailed response.
1 Like
Anyone who's having issues with jailed AGH instances? Until openwrt updates the opkg version you can bypass and either install the beta or update to latest stable by removing the opkg version and using the manual install method.
1 Like
Update: I've opkg updated AGH from 0.107.6-1 » 0.107.18-1 and is working flawless on my RPi4. Well, I still get random packing udp packet: dns: buffer size too small error everytime I connect phone but that's it.
Hi There,
Hope everyone is doing well!
Today, I've noticed I have a whole lot (>9 K only today!) of queries coming from my localhost (127.0.0.1) in my log.
All of them are PTR (xxxx.in-addr.arpa) queries.
I am pretty sure I messed up with some config, I just don't know exactly which one 
.
Any help is appreciated!
EDIT: I now suspect this started after I've installed the "bandwidthd" package. Every 2-3 mins I see a ton of those PRT requests in the log. This is the same refresh cycle as the "bandwidthd"...
they should be resolved by openwrt (if that is doing your dhcp). Make sure the ptr setup is set to use dnsmasq. https://openwrt.org/docs/guide-user/services/dns/adguard-home#reverse_dns_rdns
If you have a different setup (eg if you using AGH on another device you need to add this to the upstream server list as follows.
[/168.192.in-addr.arpa/]192.168.1.10
or whatever your device is.
However I know depending on which version of AGH you have installed... they did patch a number of PTR issues. I know its been referenced in a earlier post in this thread. I know its fixed in 108. I'm not sure which version of 107 they patched it to.
Edit: found it. [How-To-Updated 2021] Installing AdGuardHome on OpenWrt [Manual and opkg method] - #231 by mercygroundabyss that post.
Thanks a lot.
I will double check everything as per your suggestions.
I am running AGH on the the same Openwrt box i use as router, running the DHCP server for my LAN. It is a Nano PI 5.
As for the AGH version,I am running the Openwrt opkg version 0.107.18, which by the way I was having a documented issue that was preventing me to start the service. I temporally resolved that by making hosts = false in the AGH config file (https://github.com/AdguardTeam/AdGuardHome/issues/5264)
Thank you!
EDIT: PTR settings are as per the guide. I stopped bandwidthd and those queries from the localhost stopped. I am not really sure why they are not handled by Openwrt. Well, I do have a DNS forward set to the Openwrt IP on my dnsmasq though..
AGH DNS Settings:
One log entry of those thousands of PTR requests in the log:
I never edited the adguardhome.yaml file during installation until I ran into trouble updating and installing packages via opkg line commands and the Luci interface. Opkg would time out on requests and give me error messages when trying to update. I did not think it was necessary to edit the adguardhome.yaml file, since I chose for Adguard to listen to the br-lan interface only during setup. After what seemed like ages of trying different solutions, I decided to edit the yaml configuration using WinSCP, as described in the example, and, to my surprise, opkg responded as intended. Just putting it up there for someone who comes across the same issue as I have. Solving the opkg issue now means that I can use Adguard home and install/update packages as appropriate. I'm posting this here if anyone else comes across the same issue.
Sounds like your upstream DNS for your router not right. What you are describing is the router not having a separate DNS and instead is looping back through your AGH.
Make sure you don't have your upstream peer DNS ignored, or use my script to set a upstream DNS for your router using the routerDNS.sh script.
or do the following to re-enable using your ISP's DNS on your wan.
uci set network.wan.peerdns="1"
uci set network.wan6.peerdns="1"
Hi, indeed they were both set to "0", i.e. ignoring advertised DNS server addresses from my ISP.
I switched both back to "1" as indicated. Anyway, that did not help as I continue to see tons of PRT requests coming from 127.0.0.1 every 2.5 mins due to "bandwidthd" trying to resolve hosts for my LAN.
All the rest works as expected, i.e. all the other individual hosts on my LAN show nicely in the logs.
This is what happens when I try to nslookup form the router's "diagnostics" tool within Luci:
Shouldn't those local lookups be going through 127.0.0.1:54 instead, as my dnsmasq is running on port 54?
Also, in my yaml config file, I had to set hosts: false as this is the only way to start ADG without a FATAL error.
ensure your ptr lookups inside AGH are pointed at dnsmasq on port 54.
However I have had someone report they had to add their dnsmasq as an upstream to do lookups.
[/168.192.in-addr.arpa/]192.168.1.1:54
I suggest filling an issue on AGH bug tracker as to why ptrs are not being properly looked up.
That is a confirmed bug on 107 branch. See here
A way round this is to uninstall the opkg version and use my script to install the beta version, or remove the beta part to install the 107 updated branch direct from AGH team.
Once again thanks a lot!
Just to confirm, yes PTR lookups are directed to dnsmasq port 54 in AGH:
Thanks!
1 Like
Thank you for trying to help, but my issue was solved as my previous post explained. I ran your routerDNS.sh script when I setup Adguard home on my router. Editing the Adguardhome.yaml file resolved the issue for me.
opkg not updating means your router DNS is looping via AGH. that is an incorrect configuration. Your router should be able to do DNS lookups on its own. An inability for it to do this will mean NTP updates will fail and your router clock will be incorrect and potentially cause other issues like SSL failures due to time sync issues. Either fix it so your ISP DNS is used or use the script to update your router to use an alternate DNS. The reason the router DNS is kept separate is due to the delay in AGH starting when the router boots. The router should have already booted, gained a connection and updated NTP time by time AGH starts.
Your AGH clients will still use your encrypted DNS provided by AGH.
(Slightly OT, sorry:) Per the AGH logs, Google Chrome (macos and android) is doing something a little odd. Whenever a domain is blocked (either by "default" behavior, resulting in 0.0.0.0, or NXDOMAIN behavior), Chrome immediately tries the same domain with my (local) search domain appended.
So if my search domain as handed out by DHCP were scorchedpotato.io, a blocked request from Chrome for evilhost.evil-tracker.com will be immediately followed by a request for evilhost.evil-tracker.com.scorchedpotato.io, which of course returns NXDOMAIN. Anyone else notice this behavior? No big deal but it does mean a wasted request to my router's local DNS for every request blocked by AGH and it'd be nice to know why Chrome is doing it and how to turn it off.
So far I haven't seen any other client do it apart from Chrome. Sorry to be a little off-topic, but it's something I've observed using AdGuard Home's logging and as a result of AdGuard Home blocking, and it's puzzling me. I assume Chrome thinks any request that returns 0.0.0.0 or NXDOMAIN might be for an undecorated hostname, so it tries appending the search domain just in case.
That is why.
I did find articles about that, but this seems somewhat orthogonal to that. The article describes Chrome initially attempting random lookups to see if ISPs are doing NXDOMAIN hijacking before deciding whether to enable its omnibox (search and url in the same address field) feature. What I'm talking about is appending the search domain to every failed lookup and trying again, every time.
Well, it does seem intuitive why they do it, if annoying. it's of course non standards-compliant and other browsers don't do it. It'd be nice to turn it off.
1 Like