Suggestion: Separate system's resolver from Unbound

[senseivita]

A super awesome feature of pfSense is that it facilitates for packages such as pfBlockerNG serve dual purpose to filter DNS in addition to L3 and L4. It sort of indirectly filters a little L7 without Suricata if you think of it.

The problem occurs when you need the system itself to be able to resolve LDAPS servers, specially if leaks want to be avoided. As we know, anything using TLS needs to be resolved by a matching address in the certificates it's using, thus addressnig the LDAPS servers via IP addresses isn't commonly an option.

And while the system resolver can be made to query specifically the nameservers form the general section ignoring Unbound, the opposite is not true. Unbound needs the servers to exist in the system's nameservers or else it won't do a thing.

Even servers input in the advanced box seem to be needed in listed in the system's nameserver list; for instance, this piece of coded suggested by Netgate:

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 9.9.9.9@853
forward-addr: 1.1.1.1@853
forward-addr: 2620:fe::fe@853
forward-addr: 2606:4700:4700::1111@853
server:include: /var/unbound/pfb_dnsbl.*conf

...was needed before Unbound had a GUI for DNS over TLS. It still works but those servers aren't contacted if they are no in the system's nameservers.

If I want to used exclusively DoT over WAN links but I need to still be able to reach domain controllers for LDAPS, I end up needing to add something like:

server:
forward-zone:
name: "splitdnszone.tld"
forward-ssl-upstream: no
forward-addr: 10.11.9.20@53
forward-addr: 10.11.9.21@53
forward-addr: 10.11.9.22@53
forward-addr: 2001:db8:1:1fe::20@53
forward-addr: 2001:db8:1:1fe::21@53
forward-addr: 2001:db8:1:1fe::22@53

# Unbound override section only allows one DNS domain override
# or it ignores the configuration. It doesn't make clear if it ignores 
# from the repeated entry onward or the whole thing. Adding 
# domains overrides like this allows adding multimaster/redundant domains.

per each locally hosted domain plus easily conflicting confusing rules because the source of the DNS traffic coming from the firewall.

To fix this, the easiest solution is just adding a second firewall, with that you know for sure where the traffic is coming from, going to, going as (UDP53, DoH, DoT) and it solves a ton of problems that come with DNS. "Easiest" might be a little bit of a stretch for some people though, I'm used to dealing with AD and it stills caught me off guard from time to time. Furthermore, now that consumer-oriented devices like Synology servers have full domain controller (not just domain join but actual participation as AD DC, I assume with FSMO and all, I don't have one of these) capabilities everyone should take advantage of central auth which brings me back to LDAPS.

In order for "edge" pfSense to use LDAPS and act as a filter, I need it use a locally controlled DNS server, the edfthe contact the edge may or may not contact the DCs directly, since the other DNS server would be using central authentication as well, there would be a link to the DCs there anyway, it looks something like this:

Unbinding pfSense from Unbound () frees Unbound up, obviously, and there's isn't need anymore for a second system to transform the traffic so it's easier to maneuver. I use a remote gateway for its static address so its just there not doing much much of the time so I take advantage of it so I have an extra easy-to-make rule because its address falls under RFC1918 on IPv4 therefore it's not subject to firewall rules, traffic is sent already as DoT to keep security in case the tunnel breaks and traffic fails over to public VPN or ISP. It's reachable over standard DNS on UDP53, useful for testing local servers.

Why not just install BIND in pfSense?

pfSense's for OPNsense on first impression seems like it's fixed this because it's got a plugin repo that's packed with options, like REALLY PACKED, so even though it also comes with Unbound and it's also tied to the the system's nameserver list like in pfSense, its version of BIND comes with its own DNLBL lists, it has a dedicated DNScrypt Proxy with its own DNSBL lists as well, not enough? It can divert the queries over TOR, or Shadowsocks, it's Unbound unsurprisingly has yet another blacklist completely independent from the others. It's very cool until you realize what there's not there, pfSense uses the blacklists for BOTH DNS and the firewall, OPNsense doesn't have a block by ASN feature, nor comes with a magic solution for all of these lists possibly the same thing repeated over and over to share the reources a single instance of them would need. In other words, pfSense if more efficient. There's a lot more idiosyncrasies but I think uncoupling either permanently or have and checkbox somewhere to make Unbound an independent package just to have an additional resolver alone is worth it.

Or course adding a third or fourth DNS resolver is a bad idea either. You can never have too many DNS resolvers. It's very handy for geoshifting resources, sure zone views is a thing and as usual there's an overly complex unintuitive Policies counter by Microsoft but this are not easy solutions, both lack a GUI to begin with. Well, pfSense has one for BIND but it is undocumented. Most of it is.

Anyway, I'm just floating the idea and why I think it makes sense for pfSense (accident, I promise) hopefully it's developed into the software someday. OPNsense's similar behavior sort of hints it might be hardcoded in Unbound/FreeBSD or something but then again it just might be that OPNsense didn't fork far enough and kept status quo. If I knew how to code I'd be on it already but I can only pass it along. :/