Set pfBlockerNG to send fake response, good or bad idea?
-
First time poster,
Not sure if generally recommended against or any issues in the foreseeable future but I'm having some issues with certain problem devices (Roku and Apple) that are spamming pfBlockerNG due to a few domains that are blocked.
So as a test I setup a manual host overrides for the two domains cloudservices.roku.com and scribe.logs.roku.com. First testing with a random IP that is not in use on my network, this did little to change how often they were querying these. Second set of tests I used the IP of the pfSense and saw a massive reduction in queries (multiple per second vs 1 every 30 seconds).
Is this something that is considered generally ok and a way to reducing noicy devices or is this something that is generally recommended against and I should continue to let these devices spam DNS vs attempting an HTTPS session every 30 seconds?
Lastly, if this is something beneficial is this something pfBlockerNG can do natively or is the host overrides in DNS Resolver the only method at this time?
-
Well looks like I already found my answer in a completely unrelated post with the Global Logging/Blocking Mode setting under DNSBL. Well I hope this helps someone else answer this question in the future!
-
@enlinks said in Set pfBlockerNG to send fake response, good or bad idea?:
is this something pfBlockerNG can do natively or is the host overrides in DNS Resolver the only method at this time?
That's all pfBlockerNG-devel (DNSBL) actually does : it creates a big list with host names that will get overridden to 0.0.0.0 (or 10.10.10.1) instead of getting resolved.
-
Thanks for the reply!
Yeah that makes sense, I'm not sure how I overlooked that.
The original reason for the host override was because scribe.logs.roku.com and cloudservices.roku.com were returning ServFail on AAAA for some reason.
Some further digging around I enabled "no AAAA" put thoses domains there instead. Which is still odd that this is even a thing since I have no IPv6 on my network but that's another rant for another post.
In terms of what I have found, I did enable level 5 logs but the most I was able to dig up in the resolver.log was this "python module exit state is module_error" after the AAAA record was requested. I can put it back into the broken state to debug it further but I'm not really sure where to look from here myself
