BIND + Unbound (pfBlockerNG)
-
@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.
