I am currently running AdGuard Home and Unbound on a Raspberry Pi 4B and was wondering about a few DNS settings within the AdGuard Home web GUI.
Specifically:
Enable EDNS Client Subnet (First Image)
Enable DNSSEC (First Image)
Use Private Reverse DNS Resolvers (Second Image)
Enable Reverse Resolving of Clients’ IP Addresses (Second Image) Images attached below…
Enable EDNS Client Subnet
I believe I read somewhere that this isn’t something that is required for a locally server DNS Server, but I am interested in hearing opinions (and what exactly that it does).
Enable DNSSEC
Correct me if I am wrong, but shouldn’t this be enabled since I am using Unbound, which is a DNSSEC Resolver?
Use Private Reverse DNS Resolvers
As of writing this post, I only see my LAN Clients’ IP Address rather than their Hostname - however, I do not mind NOT seeing their Hostname. The reason that I have not set this up is due to the fact that there are many topics/forum posts/articles/blogs out there that have different opinions of what should be entered into the text box. When I was using Pi-Hole, I was able to use the Conditional Forwarding setting to see the Client’s Hostname, but as I said, I never really figured out how to accomplish this with AdGuard Home. Would it be my router’s IP Address? Or some other text/string?
Enable Reverse Resolving of Clients’ IP Addresses
Although I am not sure what PTR requests are, I do recall reading something that suggested this won’t work since I am using Unbound, but I am interested in hearing opinions.
As always, I appreciate anyone’s assistance and/or insight!
EDNS is an extension of the 512 bytes DNS UDP packets to allow adding additional information. It is used e.g. as well for DNSSEC. However, the first checkbox is about EDNS Client Subnet (ECS), which adds parts of the client’s subnet to the DNS request. This can be used by DNS servers to resolve names to CDN IPs which are geographically near the client to speed up it’s (final) requests. But of course this only works if the final hostname/resource is served via some CDN and if the upstream resolver and authoritative DNS server support ECS. And it can be seen as privacy issue, which is why e.g. Cloudflare doesn’t support it/doesn’t forward that info: EDNS Client Subnet - Wikipedia
If you use Unbound, you don’t need AGH to do DNSSEC as Unbound is doing it already.
For private reverse DNS you enter the IP of your DHCP server (router), yes. PTR requests are reverse DNS requests. The first checkbox below that is to resolve local PTR requests from clients via the configured local resolver (router), instead of sending them upstream, which definitly makes sense. The second checkbox is about AGH to reverse resolve IPs of it’s clients to show them in log/dashboard, AFAIK, which you can leave disabled if IPs are fine there.
Hmm, ok… I suppose the ‘Description’ under the checkbox is what confused me. I originally thought (based on the Description under the checkbox) that AGH flags the outgoing (i.e.; going to Unbound) DNS queries with a DNSSEC flag to be processed by Unbound as such - but now that I think about it (and as you mentioned), Unbound resolves the queries using DNSSEC anyway, so there is no need to have this box checked.
Enable DNSSEC: Unchecked
Use Private Reverse DNS Resolvers
This is where I am still a bit confused. I am using ASUS-WRT Merlin firmware on an ASUS RT-AX58U Router with it configured to force all Clients to use my Network Pi (Raspberry Pi 4B running AdGuard Home and Unbound) as the local resolver - so if I were to input my routers IP address into that text box to resolve local PTR requests, wouldn’t the router just send them right back to the Network Pi again?
Enable Reverse Resolving of Clients’ IP Addresses
Again, a little bit confused - the description on the Web UI, and the description on their GitHub Wiki don’t make clear sense to me. What is the difference between this and Use Private Reverse DNS Resolvers?
Why not asking these questions on the AGH GitHub? If the explanation is not clear enough, it might be good to let them know. Probably they could make it more clear.
The router should have two DNS related settings: When it’s the DHCP server, there should be a setting about which DNS server to pass to DHCP clients. I suppose this is what you set to Pi-hole. The second is the upstream DNS which the router itself uses, i.e. if it receives DNS queries or needs to resolve a hostname for itself. This is likely your ISP’s DNS by default, or a different upstream provider.
If the router receives a DNS or PTR request, like from AGH, it should be smart enough to resolve it based on DHCP clients and otherwise known LAN hostnames and IPs by itself and send them upstream only if it doesn’t know them, or not at all for PTRs at LAN IP ranges.
The first PTR-related setting in AGH is about whether PTR requests from its clients are resolved by the router. E.g. if some app wants to show hostnames instead of IPs, like an IP scanner or other network-related app.
The second setting is only for AGH’s own DNS query log and info on its dashboard. At least this is how I understand them and how a separation would make sense.
I then have DNS Filter rules setup to force all Client’s to use the Network Pi just in case a Google related device tries to bypass it. When this happens, AGH shows the router’s IP in the Query Log instead of the device that’s trying to use it’s own hard-coded DNS - not being able to see the specific device isn’t a problem for me since I only have a few devices that do this (about 3-4 out of 70 connected devices).
And finally, I have the router’s WAN DNS set to Cloudflare’s 1.1.1.1 / 1.0.0.1 for it’s own DNS resolution needs (updates, time check, etc…) but not for any LAN devices.
I entered my router’s IP address in the text field and checked the second box for Enable Reverse Resolving of Clients’ IP Addresses. I cleared the statistics with AGH and started seeing my LAN Client’s Hostnames.
I then ran Angry IP Scanner and found that the hostnames were not being resolved. So I then checked the Use Private Reverse DNS Resolvers box in AGH and re-ran Angry IP Scanner - and the hostnames were showing up.
In a basic sense, Use Private Reverse DNS Resolvers is only for LAN clients’ use to resolve local hostnames (e.g.; Angry IP Scanner). And Enable Reverse Resolving of Clients’ IP Addresses is used only by AGH to resolve the hostnames of Client’s that are sending requests to it. Correct?
I also noticed on AdGuard’s Wiki that they suggest using addresses like [/in-addr.arpa/]192.168.x.x for the Reverse DNS function - do I need to format my router’s IP to something like this?
Last, but complicated, question…
I use Tailscale on many of my devices. I have read almost every Tailscale Support doc relating to ‘Exit Nodes’, ‘Subnet Routers’, and DNS (including Magic DNS). Is there anything special that I need to do with AGH/Unbound to ensure proper functionality while using Tailscale as an Exit Node (traffic tunnel), Subnet Router (ability to access local subnets), or utilizing my Network Pi’s DNS Server (via Tailscale DNS / Magic DNS)?
Thanks for verifying, that all looks correct then. About DNS filtering: Shouldn’t this be 192.168.x.y for the Network Pi then instead of 1.1.1.1? How does it work? Does the router somehow intercept DNS requests and redirects/forces them to the configured IP? I hope this isn’t true for Unbound as well, if I understand it right . But you would recognise it quickly when changing the IP to the AGH host, as it would cause a DNS loop then.
Some browsers/apps btw can use DNS-over-HTTPS (DoH) which breaks all ways to detect/intercept DNS requests.
The in-addr.arpa prefix is common for PTR requests, so, without looking at that Wiki, I guess it’s not a suggestion but a hint that this is what you see in logs when PTRs are done.
In case of Tailscale I’m not sure how DNS is handled by it. In case of OpenVPN and WireGuard, the DNS server can be forced by the VPN client/config, so you can use AGH remotely and with WireGuard even quite easily configure it to only tunnel DNS requests, so the WireGuard client is nothing else than your remote ad blocker while all other traffic isn’t tunnelled. I guess Tailscale nodes/apps can as well be configured to enforce a different DNS when the connection is up. If you connect to the AGH host directly, its IP could be used then, if you connect to another host within your LAN, then this host needs to have IP forwarding enabled so that you can access the LAN (Subnet Router). That is however done OOTB when you install Tailscale via dietpi-software.
The ‘Custom DNS 1’ above isn’t currently being used. The DNS Filter feature on this router allows you to assign custom DNS servers to individual devices (or not, which is why the Network Pi is set to no filtering since I don’t want it to be using it’s own server to resolve queries). The first image I posted of the router settings (LAN DNS) is what is doing the DNS routing to the Network Pi.
The reason it is up there is because I was troubleshooting intermittent issues with all of my Kasa Devices going offline randomly. They are extremely chatty when it comes to querying my router/DNS server. The devices would lose connection randomly and I have been using process of elimination to figure out why this was happening. I originally thought it was due to network congestion and frequency/channel overlapping (I live in an apartment complex), but that wasn’t it (after adjusting the 2.4Ghz channels and such). So then I thought it was the router not being able to handle 70+ devices - well that wasn’t it either. I then thought it was Home Assistant’s ‘Polling for Updates’ feature - nope, that wasn’t it either. I then installed a local time server on the router via ‘chrony’ and forced all Clients to use it rather than query NTP or Time.Gov servers, but I didn’t see any drift or jitter issues. Finally, a few days ago, I decided to use the router’s DNS Filter function to have all of the Kasa Devices use 1.1.1.1, hence why that is still listed in the image. But this didn’t solve the issue either, which is why you don’t see any other devices using the DNS Filter other than the Network Pi. I just need to delete it out of that field since I am not using the DNS Filter to point any device to 1.1.1.1.
So here is what is funny about all of this - since checking the box for Use Private Reverse DNS Resolvers earlier today, the devices haven’t gone offline at all. AND, I am no longer seeing any in-addr.arpa queries in AGH coming from the Kasa Devices (which after Google’ing, I found that when I see that coming from a Kasa Device, it means it’s in conflict and offline). Which now makes perfect sense because I am using Home Assistant to locally control these Kasa Devices, and because apparently I had AGH dropping PTR requests (i.e.; that box in AGH wasn’t checked), they were causing conflicts. So you guys answering these questions for me actually helped me fix the issues with the Kasa Devices. Crazy right?
Yeaaaa… I’ve known about this issue for a while but I honestly never did the research into finding a way to stop that from happening. I know AGH has a Settings subpage where you can setup DoH and DoT, but I don’t know enough about certificates and all that stuff. I wish I knew more.
So I guess that I don’t need to add this prefix to my router’s IP address then, since it’s working fine now? But knowing that this is the prefix for PTR requests, it makes perfect sense why I was seeing these in AGH’s Query Log for my Kasa Devices (as I mentioned above).
So this is another thing that’s really funny. I have been using Tailscale since the end of last year with great success, and when setting up Tailscale on Diet Pi and other Linux devices (prior to Diet Pi offering Tailscale via dietpi-software), you have to setup IP Forwarding (as you mentioned) during the setup via echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf. And I recently had to re-install Diet Pi on one of my multi-use Raspberry Pi’s (named “KeyLime Pi”) and decided to use the pre-packaged Tailscale via dietpi-software - but when I went to unhash echo 'net.ipv4.ip_forward = 1 in sysctl.conf, I noticed that it was already active! I am glad you guys set this up this way! BUT, for some reason, Jellyfin (one of the many software packages installed on my KeyLime Pi Server) does not like when IP Forwarding is setup. It was acting as if it was a Client rather than a Server. So I had to stop IP Forwarding when I was setting it up through the web UI. Once I finished setting up Jellyfin, I re-enabled IP Forwarding and everything worked as is should be. I have no idea why, but I’ll leave that up to smart minds that my own.
Correct - I currently have two servers running as Exit Nodes and Subnet Routers - one is at my apartment and the other is as my Mother’s home. I have my apartment’s AGH/Unbound server set as the Global Nameserver with the “Override local DNS” toggle set to on. This way, no matter where I am, I am using my own DNS Server. The tricky part is setting up each device (on two separate LAN subnets) to use the proper DNS and local subnets since I don’t want the devices at my Mother’s house using my apartments AGH/Unbound server because I already have a Pi doing this locally at her house. Tailscale makes most things easy to understand and setup to accomplish this, but it can get confusing and rather tedious.
I was basically wondering if there was anything else that I needed to configure on my apartment’s Tailscale network to ensure there are no conflicts, but it seems that I have everything set up correctly. I plan on setting up Tailscale on all of my devices that it can be installed on because using my apartment’s Tailnet seems to be processing traffic much much faster than it is on my LAN - which I believe is due to the direct access to my Network Pi via the Tailnet. For example, I have 3 Raspberry Pi Zero W’s running a Pi Cam on each (to monitor my puppy when I am away), and one Pi Cam at my Mother’s house. I am using the KeyLime Pi server as a consolidated MotionEye server to view all 4 of these devices, and when I added the Pi Cam at my Mother’s house to KeyLime Pi’s MotionEye server via a Tailscale IP address, there is hardly any latency at all (mind you, I have 1 gig up/down internet speeds at my apartment and only 200mbps speeds at my Mother’s House). When I leave my apartment to run an errand and check my Pi Cams via Tailscale, there is almost no latency at all on any of the cameras. But when I am at my apartment and I try to view the local Pi Cams, there is a big latency for some reason. Hopefully that all makes sense, haha! But that doesn’t really pertain to my original questions or issues.
Here is what the DNS Filter page usually looks like. Like I said above, I only had 1.1.1.1 listed because I was directing only my Kasa Devices to 1.1.1.1 using the router’s DNS Filter function, but now that I know the issue wasn’t with DNS on the Kasa Devices, I removed it.
It’s two things, DoH/DoT support from AGH for its clients (shouldn’t be so beneficial within a trusted LAN) and clients using DoH/DoT to upstream providers, bypassing AGH. I mean every client in theory can use any DNS, ignoring the global settings of its host system, but miat software doesn’t do that. Many browsers support DoH, but it can usually be disabled and isn’t enabled by default. I heared of some iOS/macOS apps or Apple systems in general which are harder to force using the DNS provided via DHCP in some circumstances.
Since DoT uses an own port with clear protocol, it can generally be caught and filtered, but DoH has DNS requests wrapped into common HTTPS requests on port 443, hence are practically impossible to differentiate from HTTPS website traffic, but only by the target host (when being a known upstream DNS). But doing so and intercepting this traffic then breaks HTTPS authentication etc…
Exactly.
Interesting the issue with IP forwarding and Jellyfin. I remember reports with, AFAIK it was Plex, web UI showing “no server found” or something like that instead of connecting to the underlying backend. Not sure how IP forwarding is related to this since, AFAIK, it should only affect traffic to IPs other than those of the local host. Will be interesting to replicate with Jellyfin and Plex and report this upstream in case. Maybe there is a workaround or can be a solution. Would be very sad if those cannot be used in combination with a local WiFi hotspot, as router or VPN with LAN access.
Yup, that is exactly what it was saying. I can try to replicate the issue on a separate Pi later today and report back. But you are right, it shouldn’t affect it like that - maybe it was just a fluke - or maybe it had something to do with Tailscale since Tailscale has caused some interesting things to occur on my devices (no specific incident comes to mind since they weren’t a big deal at the time). Either way, Tailscale is crucial for me so a minor blip here and there (fixed by a reboot, or restarting the service) won’t really cause me any sleepless nights.
Foregoing DoT and DoH for a moment, the ASUS Router that I have actually does the Global DNS Filtering - so if a device wants to reach WAN, it HAS to go through my Network Pi because of this router setting - but it doesn’t apply to DoT or DoH, like you said.
Seems like a double-edge sword, in a way. If you want to intercept it, you break something else.
Update for the Tailscale + Jellyfin Issue(where Jellyfin was acting as a Client):
I installed Diet Pi v7 and then v8 onto an extra Pi 4B and tested the setup for Tailscale and Jellyfin. Both installations did NOT produce the issue that I came across during the setup on another Pi 4B, so I am not certain as to what happened that one time. Maybe just a fluke!
Anyway…
One more quick question for you all: Do you foresee any potential issues/conflicts if I were to setup my Network Pi (running my DNS Server - AdGuard Home + Unbound) with Tailscale running as an ‘Exit-Node’ and as a ‘Subnet Router’? Such as having to use IP Forwarding, or…?
. But you would recognise it quickly when changing the IP to the AGH host, as it would cause a DNS loop then.
