Only one DNS? Or only one firewall rule? Example 2, shows a fallback DNS pi can be used. Is it, you just can't redirect the DNS if it's using the secondary?
You can only redirect the DNS queries to one Pi-Hole.
If you use multiple Pi-Holes as local DNS servers and use the forced DNS redirection then you have to add an exception rule for the second Pi-Hole otherwise all DNS requests of the second Pi-Hole will be redirected via the first one.
Posted: Mon Jan 08, 2024 9:01 Post subject: little tip if anyone is interested in a possible 3rd method
Hey folks,
After following the guide and tinkering around for a bit, I may have found a 4th way to impliment pihole on the network. This will leverage conditional dns forwarding to you dd-wrt router for local dns lookup, but will prevent dd-wrt dnsmasq from handling any other network requests. IE you can have pihole as your primary address pushed to clients (dns address pushed is pihole, but pihole will forward your requests to dd-wrt if it needs a local address.) Thus, local DNS works.
heres what my config looks like in pihole and dd-wrt to setup. (note im including stuff for ipv6 too, which is optional. If you arent running ipv6, dont worry about the v6 stuff.)
(in my network 50.63 is the ip of my pihole. You will need to update that with your pihole's specific address).
dnsmasq config:
dhcp-option=6,192.168.50.63
domain-needed
no-resolv
server=192.168.50.63
expand-hosts
local=/little.mac/ ---------You'll need to update this with YOUR localnet address
DHCP server setup:
set to LAN&WLAN
set your local network domain
pihole config:
Never forward non FQDN A and AAAA queries should be CHECKED
Never forward reverse lookups for private ip ranges should be CHECKED
Under conditional forwarding:
enable, then set the local network in cidr notation. (mine is 192.168.50.0/24 -- yours will probably be similar. A 255.255.255.0 subnet (default in dd-wrt) will be 192.168.x.0/24) , set the IP of your router, then the local domain if you like.
ipv6 settings:
most of it is going to be specific to your ISP, but the important box is "static DNS"setting your dns server there and running radvd will push your pihole dns to clients on dhcp.
iptables rules to ensure traffic is forced to your pihole (optional but stops hardcoded stuff, typically IoT junk from trying to bypass your filtering by natting non pihole dns traffic back to pihole.:
#filter dns so its only routed to pihole
iptables -t nat -I PREROUTING -i br0 ! -s 192.168.50.63 -p tcp --dport 53 -j DNAT --to 192.168.50.63:53
iptables -t nat -I PREROUTING -i br0 ! -s 192.168.50.63 -p udp --dport 53 -j DNAT --to 192.168.50.63:53
ip6tables -t nat -A PREROUTING -i br0 -p tcp --dport 53 ! -s 2601:80:c500:94d:a00:27ff:fef6:f831 -j DNAT --to 2601:80:c500:94d:a00:27ff:fef6:f831
ip6tables -t nat -A PREROUTING -i br0 -p udp --dport 53 ! -s 2601:80:c500:94d:a00:27ff:fef6:f831 -j DNAT --to 2601:80:c500:94d:a00:27ff:fef6:f831
Dug this up from a reddit thread and hoping someone else will find it useful. Its a nice solution.
With conditional forwarding I had great infinite loops with apple devices
I looked into this point and found some references to iOS devices spamming usually for either bonjour or airplay devices on the network. Doesnt seem to indicate a loop however. If you set the local lan setting like I had posted and set dhcp for lan and wlan it does quell ios a little bit it does kind of become spammy. I have found that some devices just tend to be like this, though excessive seems to regard to ios itself having some type of issue. (seriously, the spam that comes out of my work pc when not on the vpn is pretty astounding. Constantly hits my pihole.) I am curious to what your experience was or what your setup was if it leads to other issues. Im just curious to more on this issue as it seemed interesting to me (sadly i do not have an apple device here to test with).
ho1Aetoo wrote:
Pi-hole asks router / router asks Pi-hole.
For this reason I have not provided a configuration with it
If dnsmasq cannot answer a querie, it may be forwarded to the Pi-Hole again.
And so it goes back and forth until the LAN cable melts...
It's bad to build loops at all
Looked into this as well. I was confused initially as monitoring both dd-wrt's dnsmasq server and pihole's server and not getting any loop conditions. I even tried to cause one by using dig -x on a linux machine with both valid and invalid hosts. Looks like the setup I provided may NOT actually be a loop, though there is a condition that could possibly occur to create one, though its more remote than you'd think.
I figured this out after reviewing pihole's dnsmasq config file (you can find this at /etc/dnsmasq.d/01-pihole.conf)
in there you can find these two lines which are added by the conditional forwarding settings:
rev-server=192.168.50.0/24,192.168.50.1
server=/little.mac/192.168.50.1
Those two directives are basically specifying a server to use if a set of conditions is met. or well, a zone forward if you are familiar with bind. here is where it *could loop. is if the pihole sends dd-wrt something that ISNT local and dd-wrt doesnt know what it is. I tested this scenario of doing dig-x (which does arpa lookups) of both devices it knew and didnt through pihole and dd-wrt actually did the right thing and returned nxdomains or ip returns of the device if it was found. No loops seemed to form. From the other side, having pihole as the dns server upstream to dd-wrt you get internet to the router itself, which doesnt use alot, but uses some. If you were concerned about this loop, you would simply set the upstream from dd-wrt to some other server out on the web, and make sure the iptables rules wont loop your traffic back to the router. But really, this doesnt seem to be a sky is falling issue. Long as you set a local domain name and use lan and wlan in the ui and set the directives i have it doesnt loop.
ho1Aetoo wrote:
by the way, this is a discussion thread relating to the sticky.
The thread is not intended for posting any other junk.
Understood and Im not trying to hijack your thread. I thought I would contribute to your guide by providing a potential fourth setup I discovered after reading your guide and we could discuss here. If its breaking too much Cadence I have no problem if you or a moderator wish to move this to its own thread. Im open to review/discussion/criticism of it and wanted to contribute to it somehow. .
So I had a look in my archive.
It's been over 2 years since I played with conditional forwarding.
The problem only occurred when someone was visiting with apple devices and concerns bonjour network discovery packets
I had over 100.000 queries in 2 hours - so it certainly wasn't normal network traffic. (see screenshot)
I then deactivated conditional forwarding and it never happened again
But I don't want to go into that now because it was 2 years ago and I'm not going to recreate the Setup.
Quote:
Im open to review/discussion/criticism of it and wanted to contribute to it somehow. Smile
This already starts with the fact that your configuration breaks the DNS service for all isolated interfaces - VLANs, VAPs whatever - in this respect it is just as bad as example 1
I only do this for br0 devices, which should solve the problem. (you still won't see the VAP and VLAN devices in the Pi-Hole statistics)
Code:
dhcp-option=br0,6,192.168.1.110
The statistics are just a nice gimmick anyway - how many months do you think I don't even look at the statistics? (some! the device runs in the background and dns queries are not exactly exciting)
Alternatively, you can add isolation exceptions via iptable rules (but I have decided not to offer such solutions - I don't think it's necessary to break the isolation just to have nice statistics that you rarely look at).
secondly, "no-resolv" and "server=192.168.50.63" are nonsense
you can enter the upstream DNS server under "static DNS 1"
So I had a look in my archive.
It's been over 2 years since I played with conditional forwarding.
The problem only occurred when someone was visiting with apple devices and concerns bonjour network discovery packets
I had over 100.000 queries in 2 hours - so it certainly wasn't normal network traffic. (see screenshot)
I then deactivated conditional forwarding and it never happened again
But I don't want to go into that now because it was 2 years ago and I'm not going to recreate the Setup.
Agreed, this is not normal traffic.
Those concerns seem to match with what I have found online. Seems that my setting where I configured the local lan domain was able to quiet them a little, as noticed in the threads I read.
The reason its spamming is that basically ios is scanning the local subnet for devices...
If I were a betting man id guess iOS is confused in these scenarios. By default the domain recieved by dd-wrt for local is pushed by the ISP. Therefore, I think its trying to scan THE ENTIRE INTERNET but cannot. Therefore the spam you see. Again, im going out on a limb and have no way to test this.
ho1Aetoo wrote:
This already starts with the fact that your configuration breaks the DNS service for all isolated interfaces - VLANs, VAPs whatever - in this respect it is just as bad as example 1
I only do this for br0 devices, which should solve the problem. (you still won't see the VAP and VLAN devices in the Pi-Hole statistics)
Code:
dhcp-option=br0,6,192.168.1.110
The statistics are just a nice gimmick anyway - how many months do you think I don't even look at the statistics? (some! the device runs in the background and dns queries are not exactly exciting)
Alternatively, you can add isolation exceptions via iptable rules (but I have decided not to offer such solutions - I don't think it's necessary to break the isolation just to have nice statistics that you rarely look at).
Fair enough on the vAP concern. I am not running any personally in my network, but its a good point to consider. I could test with br0 set for the push option and see if my configuration breaks.
Not too worried about stats, though I like being able to troubleshoot when a device cant get to something and easily find and resolve the issue....pihole handles that quite well.
ho1Aetoo wrote:
secondly, "no-resolv" and "server=192.168.50.63" are nonsense
you can enter the upstream DNS server under "static DNS 1"
Understood on the ui option point. However filling the options in as you state will effectively put the same options in the dnsmasq.conf file anyway, so its kind of a 6 one way, half a dozen the other issue. Both do the same thing to the file, just exist in different places.
All no-resolv does is prevent use of the resolv.conf file. Could likely be removed.
ho1Aetoo wrote:
as I said, I recommend and use example2 - there are no isolation and compatibility problems and also no loops
Understood, my only beef with example 2 is putting dd-wrt in the middle of the chain. If we have a pihole we have a much more powerful dns server (in my setup its x86 on a vm running debian) and then were bottlenecking its performance with dd-wrt which is objectively much slower. And that would be seen with its lookup performance. With zone's setup right in how I shown, no traffic goes to dd-wrt dns unless its a local lookup request.
If you set dd-wrt side with an outside server the router itself wont be registered for filtering in pihole, but given what is in most setups (ntp, ddns mainly) does it really need pihole? This has the added benefit of a secondary dns server always connected to the outside web. If you have an outage while away you can always manually swing your problem device to the router and temporarily use it for DNS as well . I think your example 2 could do this automatically but it would also open the door to leaks.
One lingering question I meant to ask but forgot...but I didnt notice an answer reading back. What is the purpose of eliminating dns cache in the router? I know pihole would have it upstream, but is there a good reason to not have it in the other devices? If anything it may optimize common queries a bit.
Understood, my only beef with example 2 is putting dd-wrt in the middle of the chain. If we have a pihole we have a much more powerful dns server (in my setup its x86 on a vm running debian) and then were bottlenecking its performance with dd-wrt which is objectively much slower.
Well, it should be clear that a powerful x86 is a bit faster.
But a few DNS queries consume practically no resources.
It should be said that dd-wrt also runs on x86 and there are popular routers such as the R7800, XR500, XR450, R7500, R7500V2, EA8500, WRT1200AC, WRT1200ACV2, WRT1900AC, WRT1900ACS, WRT1900ACS, WRT1900ACV2, WRT3200ACM, WRT32x
These have quite powerful dual core processors in the GHz range and they certainly don't mind dns requests at all
Quote:
If you set dd-wrt side with an outside server the router itself wont be registered for filtering in pihole, but given what is in most setups (ntp, ddns mainly) does it really need pihole?
But then the VAPs and the isolated VLANs are not filtered either.
Quote:
One lingering question I meant to ask but forgot...but I didnt notice an answer reading back. What is the purpose of eliminating dns cache in the router? I know pihole would have it upstream, but is there a good reason to not have it in the other devices? If anything it may optimize common queries a bit.
Yes, the cache is only used to avoid WAN latencies.
It is therefore sufficient to cache 1x in the LAN.
This also reduces CPU cycles and RAM utilization as no cache needs to be managed.
Ok thats fair.... however if one were concerned about vaps they could also set a zone for dd-wrt to forward say a specific subnet/domain back to pihole for that group or possibly do something with the firewall (pbr is a thing in dd-wrt too).
As for cache, I just was perplexed by it. I suppose local lookups are relatively fast.
In the end, there's many ways to implement this I believe, with not many being "wrong." I do appreciate you discussing this with me... Hopefully my findings will be helpful for someone. .
):