Bypassing DNSBL for specific IPs
-
@yeleek Please note, if you do an update, disable and re-enable DNSBL that line will be modified again back to the standard entry. You will need to check each time and remove any leading "server:" to ensure your expected behavior works as expected.
Just an FYI as it caught me out and is now part of my standard checks following any modifications to the configuration of my pfSense
@ kevinmitky I am doing exactly what you described. I have my dnsbl view as the subnets and am specifying specific hosts on those subnets to bypass. These are Roku's devices that had news feeds that used block sites and I made a choice to allow it access for the convenience. Ensuring the host specific acl was before the subnet based ones was something I just do based on my background, but if you don't have it in that order, maybe that's an area to check. That and having to clear any host DNS caches made this a little more time consuming to test if I screwed up the config on pfSense :-)
-
Current syntax under Services > DNS Resolver > Custom Options with Pfblockerng enabled is:
private-domain: "plex.direct"
server:include: /var/unbound/pfb_dnsbl.conf**I have a multiple devices I want to bypass dnsbl (192.168.1.50, 192.168.1.51, 192.168.1.52) but everything else on 192.168.1.0/24 I want running through dnsbl so as I understand it I should just copy and paste the following into the custom options field of the DNS resolver for this:
*server: private-domain: "plex.direct" access-control-view: 192.168.1.50/32 bypass access-control-view: 192.168.1.51/32 bypass access-control-view: 192.168.1.52/32 bypass access-control-view: 192.168.1.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes include: /var/unbound/pfb_dnsbl.*conf
-
@TupleButter Basically yes. although in your samples you have some "*" in places I don't expect. i.e. *server:
In my active config the last line is: -
[Edited] My original was incorrect as it was changed following an update. You will need to keep checking this line if there are any changes, as it gets auto added with server: prefixing it.include: /var/unbound/pfb_dnsbl.*conf
TBH its been a while since I set this up, so not sure if you need to repeat the server: tag again.
As a note, if you ever enable blocking of banned or emerging hosts you will need to include that config file in each view
My custom options currently are: -
server: so-reuseport: no private-domain: "plex.direct" # bypass view for Roku IP addresses access-control-view: 192.168.1.51/32 bypass access-control-view: 192.168.1.61/32 bypass access-control-view: 192.168.1.83/32 bypass access-control-view: 2601:xxxx:xxxx:xxxx::/64 dnsbl access-control-view: 2601:xxxx:xxxx:xxxx::/64 dnsbl access-control-view: 2601:xxxx:xxxx:xxxx::/64 dnsbl access-control-view: 192.168.1.0/24 dnsbl access-control-view: 192.168.2.0/24 dnsbl access-control-view: 192.168.3.0/24 dnsbl view: name: "bypass" view-first: yes include: /var/unbound/host_entries.conf view: name: "dnsbl" view-first: yes include: /var/unbound/host_entries.conf # local-zone: "youtube.com" inform_deny # local-zone: "facebook.com" inform_deny include: /var/unbound/pfb_dnsbl.*conf
This ensures plex works, unbound is multithreaded, includes my IPv6 subnets (obscured in example) provide bypass for selected hosts (in this case only Roku and they are IPv4 only), denies access to banned or emerging hosts.
The two commented out local-zone's are my sledge hammer approach to blocking social media for some of the younger members in the house when they get grounded! They are not currently grounded :-) -
I have followed the above and put this in my unbound custom options and it doesnt block the ads
server:
private-domain: "plex.direct"
access-control-view: 10.10.0.0/24 bypass
access-control-view: 10.0.0.0/24 dnsbl
access-control-view: 10.0.8.0/24 dnsbl
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
include: /var/unbound/pfb_dnsbl.*confif i get rid of everything and put it back to what it was before which was the below then i get adblocking but of course it happens on every network. I just want adblocking on my guest network and openvpn network for now
server:
private-domain: "plex.direct"
server:include: /var/unbound/pfb_dnsbl.*confMay someone help please?
-
@ryk48 said in Bypassing DNSBL for specific IPs:
rivate-domain: "plex.direct"
server:include: /var/unbound/pfb_dnsbl.*coRemove the server: from this line.
server:include: /var/unbound/pfb_dnsbl.*confIt should be like this: include: /var/unbound/pfb_dnsbl.*conf
Note that every time you perform a change in pfblocker, you will have to remove the "server:" from unbound custom options.
-
@mcury
Right.. Its what i did above and what my current config is. What i mentioned is what i had before i made the changes which was the config below without all access control stuff.I think my problem might be because im running an active directory domain and all my computers are set to use a windows dns server which forwards to pfsense to do dns over tls so im thinking no matter what network i put in the access control view it will be blocked if i do dnsbl on that network since pretty much everything has its dns set to my windows dns server, except the guest lan.
For example:
My windows dns server is on 10.10.0.0/24 network
my windows pcs are on 10.0.0.0/24
opendns computers are on 10.0.8.0/24
guest is on 192.168.10.0/24my windows pcs have their dns server set to the dns server on the 10.10 network so i think if i dnsbl on the 10.0.0.0/24 network its not working because windows computers dns are pointed to the dns server on the 10.10.0.0/24 network which wouldnt be dnsbl. Also i think id have the same problem on my opendns network as well since its dns servers also point to my windows dns server so i can rdp into network pcs. If i am wrong in how this works please chime in. Sounds like i might need dns servers for each network?
Ideally i just want to do dnsbl on my guest and opendns networks because i want guests to have adblock. I also want to connect to my openvpn server from my phone and browse the net on my phone with no ads and in addition have the ability to rdp into my pcs and servers but how can i achieve that when the opendns network dns points to the windows server network?
-
@ryk48 I have been looking for a pfsense solution to this for awhile. It seems the Unbound views might accomplish what I need as well, but what a pain in the ass to setup and manage. I have been investigating the Sensei plugin for Opnsense. It looks sooooo amazing and does exactly what you are asking about with ease. Policy based filtering! I just really like pfsense and didn’t want to have to reinstall my home router for one feature, but I am not seeing another option. Was hoping Sensei would be migrated to pfsense :P!
We’re you able to get this setup using unbound in pfsense?
-
@kezzla I was not. I figured since im having all of my devices on my network point to my AD DNS Server this wouldnt work. Guest lan would probably work but since i want to rdp from my phone and also block ads on my phone while connected to vpn to home this wouldnt work without affecting all pcs that use my ad dns servers.
-
Just found this thread and I think it might save my a$$ while stuck at home because of the covid19 pandemic... If I'm hijacking an existing thread, I'll move to a new one.
Basically I want all traffic on a specific VLAN (named DMZ with 192.168.2.0/24) totally bypass pfblocker & DNSBL in both directions (incoming and outgoing)... Based on OP's post, I added the following in unbound's custom options:
server: access-control-view: 192.168.2.0/24 bypass access-control-view: 192.168.1.0/24 dnsbl access-control-view: 192.168.3.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes include: /var/unbound/pfb_dnsbl.*conf
For some reasons, even after restarting unbound, DNSBL and even rebooting pfsense, I still see tons of alerts in the Reports tab of pfblocker. Using a machine on VLAN, pages are still being blocked. Clearly this is not working for me. What am I doing wrong?
Some of my settings (if it helps):
- WAN is WAN... LAN1, LAN2 and DMZ are VLAN's based on LAN physical interface
- WAN is the only interface selected in pfblockerNG's Inbound Firewall Rules
- LAN1 & LAN2 are the only interfaces selected in pfblockerNG's Outbound Firewall Rules
- LAN1 & LAN2 are the only interfaces selected in DNSBL's "Permit Firewall Rules"
-
I did a quick check on my pfSense version 2.4.5-RELEASE and pfBlockerNG 2.1.4_22 and checked I can bypass a single hosts (/32) and also changed my LAN subnet to bypass (/24) and all worked as expected.
On my setup however I do have to make sure my test PC has IPv6 disabled for DNS so it correctly matched the unbound views.
Clutching at straws, my config is not nicely indented like yours, as you will see from my original reply earlier in this thread, that did seem to cause me problems, but did not spend much time verifying it as I just removed all leading spaces and it mainly worked as expected after that.
-
This is really strange....
- If I remove the leading spaces, I cannot save the config
The following input errors were detected: The generated config file cannot be parsed by unbound. Please correct the following errors: [1586258288] unbound-checkconf[11766:0] error: local-data in redirect zone must reside at top of zone, not at zz.zeroredirect1.com 60 IN A 10.10.10.1 [1586258288] unbound-checkconf[11766:0] fatal error: Could not set up views
- I had removed the leading "server:" in front of the last line to look like this:
include: /var/unbound/pfb_dnsbl.*conf
But every time I login to pfsense and try to modify the unbound settings, it is back to this:
server:include: /var/unbound/pfb_dnsbl.*conf
Is the package pfblockerNG doing this???
-
@pftdm007 said in Bypassing DNSBL for specific IPs:
Is the package pfblockerNG doing this???
Yep.
You know now how pfBlockerNG-devel communicates the list with IPs to be blocked to unbound ^^Before you install, the custom options box (unbound) is empty :
When you dissable pfBlockerNG-debel, and re activate it :
it will add this line to the custom options (unbound) :
The first time you installed pfBockerng-devel, there was even a first comment line :
-
Okayyyy... but...? That doesnt explain why the custom options with views dont work (and dont work if I remove the leading spaces), and how to prevent pfblockerNG from adding the redundant "server:" statement in front of the line....
Others in this thread have successfully used views while using pfblockerNG so there's something I am doing wrong...
-
Which version of pfBlockerNG is installed?
Although I did upgrade mine last night to -deval 2.2.5_30 and quickly ran the same test and it still works fine.Note: upgrading, installing, disabling / enabling etc. will always add the "server:" prefix to the include line. I just have a note to always check and remove it. Am not aware of any workaround.
Based on your error there is another thread from 2016
DNS Resolver cannot be modified or changedSeems to be something regarding the System Domain Local Zone type setting. Mine is Transparent which seems to be OK and allows me to save the config and views do work. If its not this, there must be something else, so will need a little more info on your setup and config.
i.e. Do you have IPv6 configured? That will change a number of things that need additional configuration.
-
@pftdm007 said in Bypassing DNSBL for specific IPs:
and how to prevent pfblockerNG from adding the redundant "server:" statement in front of the line....
Well ...
Have a keyboard ?
Here it is :/usr/local/pkg/pfblockerng/pfblockerng.inc line 1289
$unbound_include = "server:include: {$pfb['dnsbl_file']}.*conf";
Take note : this line is still added at the end of the unbound config file. No analyses is done for Custom options already present.
When pfBlockerng installs, or when you re-enable DNSBL mode, that line is added. -
@Gertjan
Nice!Keyboards still rule!, As "Alexa, please make change to pfSense /usr/local . . . . @ line 1289" just isn't going to hack it anytime soon :-)
-
I really wouldn't ask Alexa to do this ......
Anyway, I tried it myself.Disabled :
and forced a Update > Reload >All.
My Unbound > Custom options box is now empty.
I added a single (needed !) line :I edited the file mentioned above.
And activated DNSBL in pfBlokcerNG again :The result :
$unbound_include = "# With some comments\n# while I was here.\n include: {$pfb['dnsbl_file']}.*conf";
-
@horse2370 : pfBlockerNG-devel v2.2.5_30 is installed on my system. Seems to be the latest one. Also the thread you referred me to, seems to be a bug in Unbound or its implementation in pfsense? Still unfixed? The thread ends up dead with no answer.
If "upgrading, installing, disabling / enabling etc." will always put the "server:" statement back in unbound's custom options, then to me, pfBlockerNG's devs never intended their package to work with Unbound views. This is highly confirmed by @Gertjan's workaround to manually edit "/usr/local/pkg/pfblockerng/pfblockerng.inc"...
IMO, and this is only personal opinion, we should never have to fiddle with internal files like this way, even if it works. Especially on production systems. Will this file be overwritten once pfblockerNG is updated?
At least now I start to have a better picture on how these components interact with each others....
-
Just saw the last line of your post... No, I do not use IPV6 at all. Pretty much everything else is stock, with the exception of pfblockerNG and Snort. I also use VLAN's. Could you specify which setting you need more specifically? I will be glad to provide!
EDIT: some Unbound settings
Port 53
Enable SSL/TLS: Unchecked
SSL/TLS Cert: stock setting
Network ifaces: VLANs (see my initial post on this thread for details)
Outgoing ifaces: WAN
System Domain Local Zone Type: Transparent
DNSSEC: Checked
Python Module: Unchecked
DNS query FW: Unchecked
DHCP Registrations: Checked
Static DHCP: Checked
OpenVPN : Unchecked
Custom Options: (see my initial post on this thread for details) -
@pftdm007 said in Bypassing DNSBL for specific IPs:
Will this file be overwritten once pfblockerNG is updated?
It's part of the package - so a re install or upgrade will undo changes.
Or, before editing, make a copy of it.@pftdm007 said in Bypassing DNSBL for specific IPs:
pfBlockerNG's devs never intended their package to work with Unbound views.
It's just a way to have unbound to include a file with IP's - the scope is just 'server' (unbound dns) wide.
Btw : in my case, this file is empty, I'm not using DNSBL part of pfBlockerNG-devel - so it'a a no-op for me.
I could even wipe this line in the custom options.
( but shouldn't be surprised the DNDBL functionality wouldn't work anymore ) -
Does the order in which you put the networks in the custom configs make any difference? Like would
access-control-view: 192.168.2.0/24 bypass access-control-view: 192.168.1.0/24 dnsbl
be any different than
access-control-view: 192.168.1.0/24 dnsbl access-control-view: 192.168.2.0/24 bypass
?
My custom configs were working fine but something broke so I'm trying to nail down what it might be.
-
@pftdm007 Have you managed to save the config with the advanced options? Like remove everything and save, does that work? Just add the server: Include . . . line?
Then the views without the leading spaces?From the configuration provided, it looks very similar to mine, only real difference is I have forwarding enabled as I used SSL/TLS to my Internet DNS servers, but I had views working long before that and even before that config had to also be in custom options.
@denx I'm no expert, but based on my networking background, I don't why that would make any difference.
Best practice is general is always to have more specific matches first, but in your case they are both /24's -
@horse2370 Thanks! After messing around a bit, I discovered that the order in which you put the networks/hosts makes no difference. The culprit for my problems was, indeed, the "server" prefix in the last line. Deleting it solved the issue.
-
@denx Great - as for the server: unless you want to make the modification posted by Gertjan, keep checking if make any changes to pfBlocker as it will come back.
I have a note on in my "Change Log Documents" to verify so it doesn't bite me.To help out pfdm007, do you have leading spaces in your Custom Options?
TIA
-
Finally got to do some testing....
@horse2370 : Yes if I remove evething in Unbound's custom options box, it saves. I also managed to find a workaround:
- Shutdown DNSBL/pfblockerNG, it will remove its line in Unbound's options
- Keep everything else in Unbound's options
- Remove the leading spaces
- Save (no problems!)
- Start DNSBL, it puts back its line in Unbound's options
- Remove the "server:"
- Save the options
Now I need to check if the bypassing works, but at least I got past the saving issues....
-
After all, it seems it is working now. In retrospect, I think there are still some bugs and things to iron out, and DNSBL's devs should definitely support unbound views, but at least it all works at this moment. Big thanks to you guys!
-
I'm sure this is obvious and likely just not the way you want to go, but another solution is to create a separate interface (vlan) for certain hosts and exclude this interface from using unbound (and pfBlockerNG/DNSBL) altogether. Then just allow hosts on this interface/vlan to access "respectable" external DNS servers. I did this for a gaming PC so that I didn't have to compromise my tight pfBlockerNG/DNSBL config for the sake of a single computer that wanted to talk to the world.
-
While this solution may work for some, I would prefer to still have some blocking on the additional vlan. I just really wanted the ability to have policy based blocking like the Sensei plugin offers for Opnsense. I'm currently trying it out with the $9.99 home plan, and so far it has been working as expected. It was so easy to set up as well, it just sucks having to pay 10/month :P lol Really would prefer to go back to pfsense. My goal was to find basic ad blocking on some (adult) pc's, and much stricter blocking for my kids pc's and guest devices.
I could have used other options, like pi-hole or opendns for the kids, but I want it to all go through my router and not depend on other services. Thanks for all the input so far!
-
@mdngi said in Bypassing DNSBL for specific IPs:
I'm sure this is obvious and likely just not the way you want to go, but another solution is to create a separate interface (vlan) for certain hosts and exclude this interface from using unbound (and pfBlockerNG/DNSBL) altogether
That's exactly what I wanted to do since day 1. Read my original post on this thread:
Basically I want all traffic on a specific VLAN (named DMZ with 192.168.2.0/24) totally bypass pfblocker & DNSBL in both directions (incoming and outgoing)...
Does it mean that there is a simpler/more permanent way of doing this? You need to detail how because AFAIK, all interfaces have their traffic go through the same DNS resolver (Unbound) and the distinction between filtered or not is done at the resolver level via the line :
include: /var/unbound/pfb_dnsbl.*conf
-
It's basically 4 things.
1). Configure unbound to not listen / respond to queries from clients on the excluded interface ("Network Interface" on the general tab of the DNS Resolver settings)
2). Don't configure any NAT / Port Forwarding for DNS on that interface (i.e. don't force DNS through pfSense like you probably would for the other interfaces)
3). Configure your DHCP settings for that interface with the DNS server(s) you want to use on the hosts for this zone (eg. Google, OpenDNS, etc) OR set the DNS server manually on the host.
4). Create the necessary FW rules for that interface to allow DNS out to the open internet / to the DNS servers you specified in #3.
-
If you want to bypass all pfBlocker's functionality on your DMZ subnet and you are not whitelisting. i.e. you allow all traffic from your DMZ outbound (or at least are not blocking DNS on UDP 53), then you can keep it really simple.
For DHCP hosts, just add a public DNS server(s) in the DHCP server settings for the DMZ.
For static IP Hosts, (or DHCP if you want to do it on each host) just configure a DNS server manually on each host. It doesn't matter if unbound is listening on the DMZ interface or not, if nothing gets sent to the interface ip address on UDP 53, it won't reply.Also, by still using my local unbound to resolve, I still get local host resolution, as not all my "internal" hostnames have records in my domains public Nameservers (DNS), hence my "views" configuration has
include: /var/unbound/host_entries.conf
for both dnsbl and bypass views. My certificates use hostnames as IP addresses can change, mainly my IPv6 as the prefix is allocated by Comcast dynamically. IPv4 if I decide to move stuff around :-)
That and for my own reasons (Keeps Comcast from tracking and hijacking my DNS) I use Cloudfare's DNS via DNS_over_HTTPS, which means unbound forwards all my DNS requests encrypted to Cloudfare. If you use one of there other two DNS services (1.1.1.2 or 1.1.1.3) you can also have them filter DNS requests for you based on their own reputation models.
-
Thanks for all the good info. Agreed that unbound wont reply if nothing is sent. I went down this road because I had initially NAT'd all DNS so it had to go through unbound regardless of the intended destination. I had to reverse a few things. In a nutshell, step #1 from my list is completely unnecessary (agreed). Step #2 is unnecessary if you hadn't created a port forward in the first place.
Also agreed that the downside to not going through unbound at all is the lack of local host resolution. But, on this machine it's not a big problem.
Currently using OpenDNS (or a completely different DNS for hosts going through VPN), but will play around with CloudFlare over TLS.
-
I have followed your recommended steps, but for some reasons, clients on my DMZ are not resolving (example Chrome says "DNS_PROBE_FINISHED_BAD_CONFIG")
- I have unselected DMZ interface from Unbound's Network Interfaces.
- There are no NAT or port forward applied to DMZ (as far as I know).
- The DNS servers fields under DHCP server settings for DMZ are all empty. AFAIK, when empty it will use the general DNS servers under System > General Setup which are 1.1.1.1 & 1.0.0.1 for me.
- There are 3 firewall rules on DMZ
-> Block any traffic from DMZ subnet to LAN subnet
-> Block any traffic from DMZ subnet to "This firewall"
-> Allow any traffic from DMZ to * . *Since rules are processed top-down, I'd expect the DNS requests on DMZ clients to match the last rule??? I must be missing something! If I suppress (deactivate) the second rule (block to this FW), same problem occurs.
EDIT: In order to keep the setup as straight FW as possible, and since I do not need local host resolution, I have no issue completely bypassing Unbound and using pfsense's DNS servers directly. I just want to avoid having to configure each client manually (most of the clients on DMZ are mobile devices that I will see only once....)
-
Have you tried specifying the public DNS servers in the DMZ DHCP pool config. i.e. don't leave that field blank?
I suspect that because unbound is enabled on pfSense, the DMZ DHCP server is still providing the DMZ Interface address for DNS, I don't think its aware you are not actually listening on that interface. Not able to double check at the moment.Check one of your DMZ hosts and see what DNS IP address they are using. Is it the same as the gateway?
Just a thought . . . .
-
@horse2370 : Yeah you are right.
From pfsense:
Leave blank to use the system default DNS servers: **this interface's IP** if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.
Unbound being enabled, the interface's IP is forwarded as DNS server on clients, this is what I see from ipconfig on my work laptop running windows 10.
I will google how to keep unbound active for other interfaces and have the DNS servers forwarded to DMZ. I tried restarting Unbound but didnt help.
EDIT: Yeah... DNS Forward was disabled in Unbound's options..... I may slap myself behind the head. I now understand that I can revert Unbound's Advanced options to simply "server:include: /var/unbound/pfb_dnsbl.conf" and delete everything else since I no longer need views?
-
I think the help text means unbound is enabled on pfSense, not specifically the interface. i.e. globally.
I would just add the DNS servers to the DHCP server configuration for the DMZ. Keep it really simple. This is the same kind of recommendation used in Enterprise networks for Wireless Guest. That way, guest bypass corporate DNS and just get public.
You LAN clients uses unbound (with forwarding to Google) and DNSBL filters, DMZ clients use Google directly, etc.
-
@horse2370
I added the DNS servers (1.1.1.1 + 1.0.0.1) to DMZ's and the clients are now seeing the DNS servers with "ipconfig".Seems its all working fine for now! There is still a little issue with random skype call drops when connected to DMZ, I will investigate then open a separate thread if need be.
Thanks to all for the help and patience, especially you @horse2370 !
-
@horse2370 said in Bypassing DNSBL for specific IPs:
the same kind of recommendation used in Enterprise networks for Wireless Guest. That way, guest bypass corporate DNS and just get public.
Right !!
@horse2370 said in Bypassing DNSBL for specific IPs:
You LAN clients uses unbound (with forwarding to Google)
Euh .... Corporate clients networks forwarding to Google ??
Wrong
At least in Europe, that's not a recommendation thing, one could get fired for that. Maybe in the States other rules or reasons exist, I can't tell.
For me, "8.8.8.8" is at maximum a soHO thing.
(I really guess because our society fabricated a lot of people that are trained to "have to enter a DNS" because our ISP's trained us to do so in the past. They had their reasons, but these do not exist any more).But if someone can tell me ones and for all what the benefits are, I'll adopt "8.8.8.8" myself, promised.
Btw : don't get me wrong : I'm using gmail (just perfect for automated notification systems).
I do like their search engine a lot - it works for me
I'm not against Google as a company (how could I). -
Great! Your Welcome
Thanks for clarifying in case others also thought I recommended Enterprise customers forward to Google from their internal DNS. What I thought I wrote was ONLY referring to Guest network recommendation.
My last sentence in that post was specific to pftdm007's environment, although it should have started with "Your" and not "You" :-)
To clarify - The general recommendation is to keep guest traffic isolated from internal resources, i.e use the internal DHCP servers on the network infrastructure, such as the WLAN controllers as typically that is where the capture portal is anyway, and have them use an ISP or Public DNS (i.e. non-enterprise), instead of letting the guest traffic roam around the datacenter/datacentre servers before being routed (you can pronounce "routed" correctly :-) ) out the Internet gateway.
For the Enterprise's own DNS, it should follow standard best practices, which as you correctly point out would not typically include forwarding all your DNS traffic to Google's Public server to data mine.
As always the answer is never quite that simple and it always depends. Some smaller companies may choose to utilize a Public/Cloud DNS service as part of their security posture, but that would be an authoritative name service. Hence, one of the reasons Cisco acquired openDNS, or you could even use Google Cloud DNS among many others.Like you, I use Google, however when it comes to privacy. . . . . . not so much. Yes I'm in the states, but originally from the UK and deal with customers World Wide and am exposed to all kinds of regulations. Most good, some just plain political and a PIA. The amount of time spent on training for compliance is getting beyond a joke. Soon I won't have time to do actual work that might contravene a regulation.
My home DNS used to resolve from root severs and I have a managed provider for my personal domains for simplicity and resiliance. I certainly avoid forwarding to my ISP's DNS and even using root servers when my ISP started hijacking DNS on UDP 53.
Quick Google for a supporting article provides some details Comcast hijacking DNS
I switched to encrypted DNS on community supported DNS servers, until Cloudfare rolled out their free public service for people like me.I could see one benefit of using Google for your DNS, they would mine those requests and know what you needed to buy before you did
As with anything, there are exceptions to every rule, your mileage may vary and it will always depend!
Stay safe
-
I just realized... DNSBL can be bypassed by passing different DNS servers to my DMZ clients (so they do not go thru Unbound), but what about pfBlockerNG?
WAN is selected in Inbound, and LAN is selected for outbound, but not DMZ (so not to have pfblocker block traffic on DMZ).
In pfsense's FW logs, I see entries showing blocked traffic on WAN that is going to DMZ. This is my understanding: DMZ client sends traffic to the internet, nothing is blocked (pfblocker & DNSBL are not running on DMZ). Request gets sent to the internet, the response comes back, it is blocked by pfblocker on WAN.
I had Snort running on LAN and WAN, but not on DMZ. It kept blocking incoming traffic on WAN that was coming back to DMZ. User @bmeeks kindly explained that it was unnecessary to have Snort run on WAN. The logic is that all unsolicited inbound traffic is blocked by FW rules so only stateful responses are allowed, and since the initial traffic had gone thru Snort on LAN, it is considered "safe". Sorry for the gross over-simplification......
Is it the same logic for pfblockerNG??? How do you guys run these packages? I'm slowly realizing that I have made several mistakes in setting up my pfsense box....