Helo there!
I am currently running pfSense CE 2.7.2 and using BIND. I was expecting the package to be upgraded to 9.18 after the EOL of 9.16 this April, but that hasn’t happened yet.
I noticed that the packages pfSense uses include (to some extent) the 9.18 version, but I could not figure out any way of installing it. I tried playing with pkg search bind but this is all I got
bind-tools-9.18.19 Command line tools from BIND: delv, dig, host, nslookup...
bind916-9.16.44 BIND DNS suite with updated DNSSEC and DNS64
pfSense-pkg-bind-9.17 BIND DNS suite with updated DNSSEC and DNS64
Is there any way I’m not seeing here to get 9.18 (or 9.20 for that matter) installed? Ideally without having to fiddle with the command line, i.e. something that would be able to be exported in a backup.
Or is the solution just waiting for Netgate to update those packages?
Thanks!
Pfsense isn’t modular in the way that anyone can upgrade to the latest package. All the packages are locked for the stability of the overall software.
Hi!
Definitely, I only treat it as the appliance it is, hence why I’m not eager to use the command line. I am curious though as to why the 9.18 port exist in their repo and if it can be installed, seeing that it is even present on their release branch. I would assume it is able to be installed somehow, isn’t it?
If you want that kind of flexibility (and stability/security) you need to run Bind in a container or VM.
Hi Joe, I already run bind 9.18 in containers, I specifically want 9.18 running on pfSense the official way so I can take advantage of DoH.
Maybe I should simplify my question:
- Is there a pfSense-native way to get bind 9.18 today?
I can’t answer your question directly (not a pfsense guru), but if this crowd is quiet, then the answer is no.
On another note, I don’t understand why do you need to run it on pfsense for that? I am missing something obvious.
No real need per se. It is currently acting as a slave for the containerized one, which is running on a K8s cluster. It just makes sense to me for this particular setup to have it on the pfSense box. It is just convenient, as that pfSense has a very generous resources surplus and can run bind without as hitch.
ps. I’m not sure if I misinterpreted your question, if it was regarding DoH, 9.18 is the version in which it was implemented. To the best of my knowledge, there’s not support for either DoH or DoT in 9.16.
I get the resource point. Many years ago when I used pfsense in production I had the same thought. But treating your router as a server platform is bad design. Especially the way pfsense does it. But man do they it make it so easy. Most people skip right over the disadvantages of treating their router as a platform and never look back.
Sounds like you know how to do this the hard way (the right way). Admin by keyboard is always better than mouse.
I get it, I’ve been moving services away from that box to other machines, e.g. VPN, but DNS is just too closely related and I cannot justify dedicating anything else for bind, specially when there’s already redundancy in place for it. As of now bind is the only “extra” service running on it and it isn’t even public facing, those are running elsewhere.
Risking going even more off-topic, I’m curious why is it such a bad idea? The attack surface it adds is IMHO very minimal, resources are not a constraint and it requires no extra maintenance as it is just a slave… well, apart from me wanting to update it to 9.18. Anything I’m missing?
pfsense runs these apps without any isolation, and from what I understand many as root. It is one thing if you do this on a bare metal server (like we did 15 years ago) sitting in a rack by itself, but this is on your core router. Not to mention the flexibility and stability advantages. Bad updates, big upgrades, custom tweaks, features, scalability, rollbacks, licensing changes, fees, etc.
Regarding DNS specifically, I typically use my slave servers as front-line pawns (hidden master config). So they not only take the brunt of the performance impact, they also absorb any possible DNS attacks coming from an unfriendly LAN (assume breach right). Sounds like you are doing the same, but you are protecting your master by pushing your core router in the front line. That’s a bad chess move in my opinion.
Are these design disadvantages worth the single big advantage of being stupid simple? Nope, clearly not at the SMB level. If pfsense added a print server package people would be jumping for joy over how easy it is.
1 Like