Video about DNS blocking with pfBlockerNG starts with two rules on LAN interface designed to restrict DNS queries to servers on the LAN (which includes the pfSense box).
The rule basically says “dns query from system on LAN to server on LAN is OK”. But won’t such a query stay on the lan, and never get routed by pfSense? So why do you need the rule?
If it’s needed to allow queries to the pfSense box, couldn’t the pass rule just say traffic destined for port 53 on “this firewall (self)”?
I’ve also developed a habit with rules to use “LAN net” rather than “any” for source. This catches someone who spoofs their IP address to a non-LAN one. Although return routing would fail in such a case.
There’s actually a couple things imho, that need to be done to bind dns to pfsense, but the rule you’re referring to binds lan client dns requests to pfsense, which run a dns server on each interface that selected. The idea behind the entire dns binding is to capture rogue clients from using any dns servers besides the ones you have set up under pfsense.
Suppose a random webpage or app decides to get malicious and use their own dns server to re-route traffic, binding dns to pfsense will prevent that attack vector.
I personally have DNS and NTP bound and locked to pfSense and rules added for the ‘cya’ scenario.
The verbiage says it’s to allow clients to access dns servers on the lan (for windows).
If you just want to force clients to use dns on pfsense, why not a rule that says “accept port 53 traffic if destination is this firewall” followed by one that says reject port 53 traffic.
I also set both tcp and udp rules when dealing with DNS/port 53. This is to catch regular DNS queries that use TCP, but should also catch DNSEC