DNS Suffix Search List
-
I have a seperate Bind and ISC-DHCP server that I maintain for my 2 internal and 1 external DNS domains. The internal ones are:
dhcp.mydomain.local = Internal DHCP Clients
mydomain.local = Internal Static Clientsand the external is mydomain.com. I have the PFSense appliance (hardware) in the external DNS space, and that all works fine, except I cannot get it to resolve host name only for clients in the internal domains. Typically on a Linux system I would just add the search line into /etc/resolv.conf and call it a day, but with this being FreeBSD I am not sure on the method of doing this, or if it's something that can be done through the PFSense GUI itself.
I do plan on keeping DNS and DHCP external and independent of PFsense.
-
External DNS shouldn't be resolving internal domains in the first place. That's not a good design. External DNS for public clients, internal DNS for internal clients. Why do external clients need to resolve internal domains that aren't reachable from the public Internet?
-
They don't, but the firewall appliance needs to resolve these so in my reports I get proper hostname translation from the IP. This is not for external clients to resolve internal, purely for the firewall to resolve more than just it's own domain without needing FQDN.
-
How do you currently have DNS configured on pfSense? Forwarder or resolver? What do you have under General Setup - DNS Server Settings - DNS Servers?
-
Under the DNS Server Settings - DNS Servers I have my two internal DNS servers setup, and using Resolver.
-
if you have some internal domain you want to resolve, then you need to tell pfsense were to resolve those via a domain override.
-
So that does work for doing FQDN lookups, but doing just hostname lookup without adding the domain is what I need to have happen.
-
Just at a lost to why you think pfsense is going to be looking up just host names? If you want it to resolve something for logs it would be a PTR lookup anyway, not a A record lookup.
It would be looking for the name associated to the IP that hit it..
-
Yeah, it should only be a PTR, I've seen where this has issues without forward lookup working. But, I've been looking at implementing pfBlockerNG, so I will need to change the way this setup works by pointing my internal DNS servers to pfSense for the forward lookups, so this all is going to change anyway. So with that, I guess my question is no longer valid.
-
You can have your clients ask your internal, and have those NS forward to pfsense which then resolves - and uses pfblocker.
Pfsense will still need to have domain overrides for stuff you want it to look up that are on your NS.. but the domain overrides would be the PTR zones, not forward zones.
So you setup an override for say
1.168.192.in-addr.arpa.
That points to your NS that are authoritative for that zone.
-
Yeah, that's what I ended up doing, pointing all clients to my bind servers, then having the bind forward to pfSense, then pfSense forward to Google and Cloudflare. I put in domain overrides for local domains and reverse domains for my LAN, and that seems to be working and for the most part it seems pfBlocker is now working as expected.
A little more convoluted than I originally imagined but actually makes sense since pfBlocker is acting as a DNS Rewrite engine it would have to be the "final say" for clients on the LAN.
