Different DNS forward based on subnet/VLAN?
-
We've got multiple subnets/VLANs with differing DNS filtering requirements. (Think: opendns filter policy vs generic.) PLUS, we have a number of internal DNS host overrides.
I can configure custom DNS by interface at the DHCP level, but doing so bypasses pfSense host overrides.
Other than that, it appears that DNS resolution servers are configured at the System->General Setup level (or just resolved in pfSense.)
Question: is there some kind of other feature available (a custom/advanced DNS option?) that allows DNS forwarding to be customized per-subnet, without breaking the host overrides?
-
@mrpete said in Different DNS forward based on subnet/VLAN?:
Question: is there some kind of other feature available (a custom/advanced DNS option?) that allows DNS forwarding to be customized per-subnet, without breaking the host overrides?
I don't know of any way to accomplish that using the built-in DNS Resolver (or Forwarder) within pfSense. You can certainly accomplish it using an external DNS server for each subnet. For example, you could use a hypervisor to host as many Linux-based (or Windows, if that floats your boat
) DNS server virtual machines as needed. Then over in pfSense configure each DHCP scope to hand-out the proper DNS server IP address from all the guests running on the hypervisor. Of course that solution requires extra hardware and expense - and it would require duplicating your custom host/domain overrides on each of the guest virtual machine DNS servers.
-
@mrpete If your trying to do this all with 1 nameserver your best best prob be to use bind. When you create views with bind pretty sure it creates their own cache vs I believe unbound uses a shared cached.. But not sure if there has been any changes to that in latest versions of unbound.
The problem that can happen when you use different filtering forwarders for different clients, if you have a shared cache.. client A asks for something that is not filtered for him, and then another client comes in and gets that via cache vs what the forwarder might return for it being filtered.
Been meaning to do some testing of how best to accomplish this either via bind or unbound since this sort of question comes up quite a bit actually.
But the most straight forward solution is yes is to use different nameservers (dns) for your different clients that need to use different filtering. This way your sure all those clients will only be see a cache with their filtering done. And you don't have to worry about setting up views which can be a learning curve for users new to them.
These different NS for your different clients could all use domain override to ask say pfsense for the local resources they all should be able to resolve.
-
@johnpoz said:
The problem that can happen when you use different filtering forwarders for different clients, if you have a shared cache...
Yeah, problematic, no question.
These different NS for your different clients could all use domain override to ask say pfsense for the local resources they all should be able to resolve.
Now THAT sounds interesting.
As I'm quite sure you 'get', it would be a royal pain to have to configure a domain override set in each of multiple DNS servers.I've now examined the unbound documentation. I don't see any suggestion that it supports split cache, let alone split forwarding based on any factor of any kind. Perhaps a future-feature?
Unbound does have tags and views configurable by many factors, including IP and more. However, those only control local responses, not forwarding.
Here's a nice doc page explaining how to do exactly what we're discussing in bind. Bind views split both the DNS config and the cache. It's quite straightforward (assuming their info is correct; I've not tried it :-D) Bind views make it as simple as:
view "students" { recursion yes; forward only; forwarders { ip; ip; ip; }; match-clients { 192.168.10.0/24; }; include "/etc/bind/our-local-ip.zones"; }
(in /etc/named.conf or /etc/bind/named.conf)
Bind even supports cache controls such that (for example) a guest subnet has zero access to local client IP/name info.
Note that (as of Bind 9.7.0), multiple views can be configured to share a cache, so the result can be made as efficient as one could expect. (attach-cache cache_name;
)NO need for multiple nameservers. Looks like time for me to learn about using bind in pfSense :)
-
@mrpete said in Different DNS forward based on subnet/VLAN?:
Looks like time for me to learn about using bind
It behooves anyone doing anything with dns to learn about bind to be honest.. ;)
While forwarding per view might not be documented in unbound, the subject has come up multiple times and you might be able to put forward in your view, etc. But yeah until they have isolated cache for the different views - even if works and view X forwards to A, and view Y forwards to B its not a workable solution unless the views X and Y have their own cache.
-
@johnpoz said in Different DNS forward based on subnet/VLAN?:
While forwarding per view might not be documented in unbound, the subject has come up multiple times and you might be able to put forward in your view, etc.
Found it as an Enhancement Issue. They understand the caching implications and have no plans to implement. First raised in 2020; someone asked for an update in Nov 2022 but no reply yet ;)