BIND + Unbound (pfBlockerNG)
-
I successfully have BIND set up on pfSense, mirroring my domain zones. This allows my to bring my Windows servers down without losing local DNS. BIND is running on the default port 53.
In order to add ad-blocking to our network, I got pfBlockerNG working with Unbound on port 5353. This is tested and working.
I'm running in to a problem adding the Unbound pfBlockerNG service as the DNS forwarder for my Windows servers. I can't figure out how to change the DNS port in Windows for the forwarders so it points to 5353. I'm hoping someone can help me solve this problem; I have a few assumed solutions:
- Change the DNS forwarder port in Windows (via some setting I can't find on Google).
- Get Unbound to listen on a different IP Address on port 53.
- Get BIND to act as the forwarder for Windows, while also properly mirroring the domain zones.
My goal is to continue having BIND act as a backup DNS server for all my clients on the network, with all my WAN DNS requests getting filtered via pfBlockerNG.
-
This sounds like an unworkable situation long-term. Having two DNS services (BIND and Unbound) on the same physical box is not a good idea and is going to be very hard to get working reliably.
Are you running a Windows Active Directory domain? If so, you would usually want two domain controllers and each would be running AD DNS. In that configuration you can easily take one down for upgrades or maintenance and the other keeps the network up. No need for BIND in that scenario.
If you don't have multiple domain controllers, then your life will be easier if you use virtual machines and set up your BIND on a VM by itself, or even better, you can use something like pi-hole on a virtual machine. You can virtualize using either VMware ESXi or Hyper-V (if you prefer a Microsoft solution).
-
@Nick2253 said in BIND + Unbound (pfBlockerNG):
My goal is to continue having BIND act as a backup DNS server for all my clients on the netwo
If your an AD shop, as bmeeks stated already if your worried about NS going offline if you only have 1, then fire up dns on another AD server in your network... Or fire up bind on some other box if you so desire..
Then on pfsense just have unbound running if that is what you want to use with pfblocker, then have your ns(ers) in your environment forward to unbound on pfsense on the standard 53 port.
-
@bmeeks said in BIND + Unbound (pfBlockerNG):
Having two DNS services (BIND and Unbound) on the same physical box is not a good idea and is going to be very hard to get working reliably.
Why is this? Unless there is some magic to pfSense that I'm unaware of, they're separate services running on separate ports, and should have no conflict whatsoever. I mean, if there is something I'm missing here, I'd appreciate the heads up. But I can't understand why BIND and Unbound would inherently conflict outside of the coincidence that they respond to the same type of packets.
In fact, I have both of them working reliably right now; my issue is an external configuration more than anything.
@bmeeks said in BIND + Unbound (pfBlockerNG):
Are you running a Windows Active Directory domain? If so, you would usually want two domain controllers and each would be running AD DNS. In that configuration you can easily take one down for upgrades or maintenance and the other keeps the network up. No need for BIND in that scenario.
I'm sorry, I thought my OP made it clear that I was running an AD domain. And I also mentioned that I have multiple windows domain servers already running in this network. I probably should have explicitly specified that I have multiple redundant domain controllers running AD, DNS, etc.
My mandate is related to minimum operational setup, rather than simple fear about NS. I was hoping I wouldn't have to dive into this, since it's both complicated and company specific. Suffice to say, I must be able to support a fully self-contained DNS solution on the pfSense box. If I can't make Backup + Blocking work on pfSense, then I must forgo the Blocking part.
I believe that adding an additional PiHole VM would be out, because I assume that losing that PiHole VM would then cripple external name resolution. Is this correct? Perhaps there's a way to configure BIND with active/failover forwarders, but I'm not aware of any BIND configuration that would allow this.
-
@Nick2253 said in BIND + Unbound (pfBlockerNG):
they're separate services running on separate ports
Did you alter the control port (953) - not just their listen ports.. You have to do this as well or your going to run into a race condition on their starts.
If you want one to listen different than 53, you can do that sure - how to get your ad dns to forward to that would be a question for the windows forums ;)
-
@johnpoz said in BIND + Unbound (pfBlockerNG):
Did you alter the control port (953) - not just their listen ports.. You have to do this as well or your going to run into a race condition on their starts.
Yeah, I had to solve this in order to get Unbound to even work in the first place :)
@johnpoz said in BIND + Unbound (pfBlockerNG):
how to get your ad dns to forward to that would be a question for the windows forums ;)
Ohh, don't you worry. I've got this ask out in Windows land as well. I was hoping, on the off chance that someone here would have done something similar, that y'all would have a quick answer for me, since Windows land is letting me down. Womp, womp....
-
It's very possible that it just not possible.. MS is like that sometimes.. What version of windows servers are you running 2016? 2012? etc..
-
I didn't mean to imply it was not possible at all, but I instead meant that generally speaking it's going to be problematic going forward with updates and such as is lots of times the case when you switch things to non-standard ports and setups. Hence my choice of the word "unworkable". Maybe "unwieldy" would be more appropriate.
I'm not following something in your setup description with regards to failover. With your current setup (assuming you found a way to get Windows AD to forward to Unbound on port 5353), you still have a single point of failure with Unbound on pfSense. You would not be able to do external lookups if Unbound on pfSense went down. BIND nor AD would have anything to forward to. Implicit in this assumption is that the pfBlockerNG ad-blocking is important for you. For that to work, Unbound needs to be your only forwarding destination.
So is the problem your customer (or company) will only allow you to add one single box that has to do everything? Because without that restriction I would certainly choose to use virtual machines for this. Way easier to maintain since you can do a simple snapshot recovery and "boom", you are right back to where you were before you applied that 'latest security hotfix' that bricked the machine ...
. -
@johnpoz said in BIND + Unbound (pfBlockerNG):
It's very possible that it just not possible.. MS is like that sometimes.. What version of windows servers are you running 2016? 2012? etc..
Currently 2012 R2, but we're looking at upgrades to 2016 or 2019.
@bmeeks said in BIND + Unbound (pfBlockerNG):
... Maybe "unwieldy" would be more appropriate.
I definitely agree with the "unwieldy" moniker. However, in the name of our requirements, this is far from the most unwieldy thing I've had to do with pfSense :/
I'm not following something in your setup description with regards to failover...single point of failure with Unbound on pfSense...
The plan is to run additional internal forwarders with the same block lists to provide this redundancy. As I understand it, as long as one of the forwarders is working, I should be good, as the DNS servers will do lookups against all the forwarders until they get a response.
So is the problem your customer (or company) will only allow you to add one single box that has to do everything?
Something like that. It's more that the firewall/router appliance must be able to single-handedly provide all "core" network services.
-
@Nick2253 said in BIND + Unbound (pfBlockerNG):
It's more that the firewall/router appliance must be able to single-handedly provide all "core" network services.
That makes just no sense...Some idiots made up nonsense rule without any actual basis in reality..
-
@Nick2253 said in BIND + Unbound (pfBlockerNG):
The plan is to run additional internal forwarders with the same block lists to provide this redundancy. As I understand it, as long as one of the forwarders is working, I should be good, as the DNS servers will do lookups against all the forwarders until they get a response.
So would these additional internal forwarders all be on the pfSense appliance or some other physical device? This part seems to be tripping me up. If everything is on a single pfSense instance, then you have a single point of failure at that box. If you run forwarders on other separate hosts (with the same DNS blocklists), then sure the pfSense box (or Unbound on the pfSense box) can fail but the other forwarders will take over. If everything is on the pfSense box, then you're down for the count until Unbound on pfSense is back.
You could just use a very small footprint 1U server chassis with CPU, RAM and SSD and put ESXi on it. Then run pfSense as a VM. And with enough RAM you could run another VM or two for BIND instances. Technically that will put all the network core services on a single box. The fact the single physical box actually contains a couple of virtual machines really should not matter. It could all be configured to "auto-start" on power up, so it would be somewhat idiot-proof.
-
@bmeeks said in BIND + Unbound (pfBlockerNG):
So would these additional internal forwarders all be on the pfSense appliance or some other physical device? This part seems to be tripping me up. If everything is on a single pfSense instance, then you have a single point of failure at that box.
No, these other forwarders would be on other machines.
The point is not to make the pfSense box a single point of failure; every service provided on the pfSense box is made redundant somewhere else. The point is that, in the event of any arbitrary failure up to and including total network loss, a single pfSense box has no dependencies on anything else, and all "core" network functions can be provided by this one appliance.
-
@Nick2253 said in BIND + Unbound (pfBlockerNG):
@bmeeks said in BIND + Unbound (pfBlockerNG):
So would these additional internal forwarders all be on the pfSense appliance or some other physical device? This part seems to be tripping me up. If everything is on a single pfSense instance, then you have a single point of failure at that box.
No, these other forwarders would be on other machines.
The point is not to make the pfSense box a single point of failure; every service provided on the pfSense box is made redundant somewhere else. The point is that, in the event of any arbitrary failure up to and including total network loss, a single pfSense box has no dependencies on anything else, and all "core" network functions can be provided by this one appliance.
Okay ... but with a total network loss what would be the intrinsic benefit of still having DNS resolution on the pfSense box? What's going to use it? Not trying to be argumentative, but just trying to appreciate the design requirement.
So I still say my VM appliance would be a potential answer. You have pfSense with Unbound and pfBlockerNG in ad-blocking mode on one virtual machine, and then you have BIND in another virtual machine on the same appliance. So the one appliance would provide the core network functions required (it would be the functional equivalent of pfSense, BIND and Unbound/pfBlockerNG in a single box). But by splitting BIND out into a separate VM on the same physical hardware you dodge the issue of having to use non-standard ports. You could put BIND on its own IP address and then the Unbound service on its own IP address. Using the built-in virtual networking in VMware you still could present all of this on a single RJ45 port to the existing LAN.
-
@bmeeks said in BIND + Unbound (pfBlockerNG):
Okay ... but with a total network loss what would be the intrinsic benefit of still having DNS resolution on the pfSense box? What's going to use it? Not trying to be argumentative, but just trying to appreciate the design requirement.
Total network loss is obviously the worst case scenario. If you really had nothing else, then yes, you'd have no use for it. I would say that the idea is that the pfSense represents the minimum necessary for a working network (which includes external VPN access, site-to-site VPN for cloud services, etc.). Then, you have a proper company-specific foundation to restore services in.
So I still say my VM appliance would be a potential answer. You have pfSense with Unbound and pfBlockerNG in ad-blocking mode on one virtual machine, and then you have BIND in another virtual machine on the same appliance. So the one appliance would provide the core network functions required (it would be the functional equivalent of pfSense, BIND and Unbound/pfBlockerNG in a single box). But by splitting BIND out into a separate VM on the same physical hardware you dodge the issue of having to use non-standard ports. You could put BIND on its own IP address and then the Unbound service on its own IP address. Using the built-in virtual networking in VMware you still could present all of this on a single RJ45 port to the existing LAN.
I will investigate this solution further. I'm not sure this is really a benefit, but I will see what shakes out.
-
Using something like the VM appliance lets you avoid the hassles of running Unbound and BIND with non-standard port configurations and you don't have to get the Windows AD boxes to forward their DNS queries to a non-standard port (meaning something besides port 53). So that seems like a big plus to me. I don't really see a downside other than hardware capable of being a VM appliance is going to be a little more expensive than a plain vanilla pfSense appliance would be, but in a large corporate deployment the cost differential is probably just a small blip in the accounting ledger. The good news in your case is that neither pfSense nor BIND are big RAM users, so you don't need some huge amount of RAM in the virtual machine host nor do you need multiple server-scale CPUs.
