PiHole off:
Right now I'm on different machine 192.168.103.12 (previously on .10), so first lines in log are from nslookup that failed
PiHole off:
Right now I'm on different machine 192.168.103.12 (previously on .10), so first lines in log are from nslookup that failed
Okay, that's got some interesting parts in it.
It's still trying to use Pi-hole but there is no response back, which is exactly what we expect.
Do you have ssh
service enabled for opnSENSE? I'd like to check a few things at the console shell...
Yes I have (but only locally)
Ah, I think I've found it. Without Query DNS servers sequentially
everything works. But it should be following order so I'm going to do some digging.
I don't think we need shell access for this.
Awesome, thank you.
Okay, this is an odd one and I'm not sure how things worked for me with this issue in place.
If you remove the edns0
config and restart dnsmasq
then the strict order will work.
The problem is that ends0
precludes dnsmasq
from regenerating the query and dnsmasq
never hears the timeout and the signal to try the next server down the list.
So, for now I'd remove edns0
and go back to conditional forwarding
for the local name resolution. Should be able to set cf
to point to OPNsense (I forget the capitalization...) and use your local lan domain name.
I'm going to try and see if there is some way to fix this issue, but I don't think it will make it in to a dnsmasq
version that would be pulled in to opnsense. Unless we can chat with them and see.
@DL6ER I'll get you on MM for this, I think that ends0 = 32
should have enough information to recreate the query with the full ip and source port.
Yes it's working now (after removing ends0)! Thank you.
Two additional question (in same topic):
So instead of:
Use something like this (I think it is impossible):
You could do it a couple of ways. If you are okay with forwarding local to unbound and having unbound respond with the DHCP leases then that will work. My example configuration is designed so that there's not a possibility of leaking, as small a possibility that is.
I'll think about your idea some more and see if there's a way to do as you mention and be able to have fallback DNS without needing to tweak opnsense dnsmasq
. Credit will go to you if it works and we do a blog post about it.
dnsmasq
will ignore any DNS servers that are reachable via 127.0.0.1
or at the same IP as dnsmasq
to prevent loops. And as you saw, there is no place to put a port with /etc/resolv.conf
. (That's what opnsense changes when you add DNS servers to General settings.)
<20 minutes later...>
Okay, I think your last question sparked a bit of an idea for me. If opnsense has compiled unbound
with the required flags then we could use unbound
entirely and not need dnsmasq
. That's a better approach since opnsense discourages dnsmasq
as a resolver.
We could still use edns0
|ecs
and limit the forwarding to only the Pi-hole server. And make a local zone for the local domain name for your lan. I don't know if unbound
adds the reverse PTR records for DHCP leases, but if it does then even better.
It will take some manual configuration and files but it may work to be a more elegant solution to the problem of wanting Highly Available DNS and something to function if Pi-hole goes offline.
Give me some time to play with it and see what I can come up with.
What I would do is
I think I have something that works with unbound
and forward-first
. When Pi-hole goes offline then unbound
becomes a recursive server like it normally operates. Each query has to fail on Pi-hole first so you will have additional latency when in fail mode but that may be a good indication that you need to investigate.
Unfortunately the unbound
for opnsense is missing the ecs
module so it's back to conditional forwarding unless/until opnsense can be convinced to include the module in the compilation run.
dnsmasq
on the opnsense is no longer used at all.
Hi, sorry for late response.
I'm not sure if I understand you correctly.
You are saying that I could use unbound without dnsmasq and have fallback DNS but this require forward-first option? Is this option already available or does it require mentioned compilation flag for unbound (I don't see this option in OPNsense but maybe missed it)?
In this case if PiHole is running will it ask external DNS? This would mean that unbound functionality of asking "root" name server (not sure how they are called) would not work (it would work only if PiHole was down).
Sorry if I mixed something I'm not an network admin, I just learning on my home network, first time configuring something more advance than basic router:P
I'm working on a few different approaches.
The limiting factor is the versions of the daemons included with opnsense. unbound
is a really nice solution but it needs to be compiled with subnet
support. The default freebsd
package has that disabled and I'm not exactly sure where or who on opnsense to ask for that flag to be enabled on compile.
dnsmasq
would be another solution but it appears to have a bug when edns0
is enabled and strict-order
is called for. Fixing that would require opnsense to include the fixed version. I don't know how that would be done on opnsense either.
I do see what you mean about unbound
being both the first DNS and the upstream to Pi-hole. To solve that I would have unbound
running on opnsense as the ingress DNS and then run Pi-hole and unbound
together on the Pi-hole server. Easy to do and actually is the preferred method of using unbound
.
So, where does that leave us? If you don't want to have the clients show as individual then unbound
would work now with the two daemon configuration. There is a slight delay for the forward-first
to kick in when Pi-hole is offline but I think that's a fair compromise and possibly a signal to users that something needs to be addressed.
If anyone has contacts at opnsense that we could chat with, please let us know.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.