pfBlockerNG not working
-
@Gertjan
Thank you, but if I remove those servers from System/General which upstream forwarders will Unbound use? -
Ready to learn what a resolver actually is ? ;)
See here https://en.wikipedia.org/wiki/Domain_Name_System#DNS_resolvers - the last phrase..... For example, a possible resolution of www.example.com would query a global root server, then a "com" server, and finally an "example.com" server.
Internet uses IP's and doesn't know anything about domain names.
When humans use endless lists of numbers, things bcome messy, so domain names and host names are invented.These 13 servers https://en.wikipedia.org/wiki/Root_name_server are hardcoded in each resolvers. One of them is used, and the host name is resolved as shown.
A resolver can look up zone details without the need to ask some other DNS system.
For example, you could forward all your DNS request to 8.8.8.8 - 8.8.8.8 is a resolver. -
Thank you, I'm always ready to learn :) In this case I know exactly what a resolver is. Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints. Also, using Google DNS servers equals totally giving up on your privacy which defeats the whole purpose of this exercise...
Therefore, I am wondering if there's a way to use my ISP servers and not root hints with this setup?
-
@malf0rmedZ said in pfBlockerNG not working:
Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints
That was in the old days.
These days, DNSSEC exists, which only works while resolving from top to bottom.
ISP DNS servers still exists, their usage isn't mandatory any more. -
@malf0rmedZ said in pfBlockerNG not working:
Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints.
Nope you explained what a forwarder will do. It will forward to another system and use that for caching etc.
A resolver "resolves" the domain like @Gertjan describes by resolving it from back (tld) to front. Also a resolver includes caching itself, validates DNSSEC and is able to still goes on functioning for 99% of all domains when those forwarders others use are down again - like many of those cited ISP servers are multiple times a year. I'd never use my ISPs DNS as they have a history of "redirecting" you to other "helpful" sites instead of delivering NXDOMAIN answers. A resolver protects against such acts. -
@JeGr
Thanks but sadly this is a semantics argument. As part of the DNS name resolution process, the DNS server forwards queries to domains whose zones it doesn't host (or for which it is non-authoritative). I would like to use my ISP DNS servers as the forwarders, not root hints, so I'm wondering how this can be achieved with this setup. Thanks again. -
@malf0rmedZ said in pfBlockerNG not working:
Thanks but sadly this is a semantics argument.
No it isn't. It's a function. There are DNS forwarders - like DNSmasq - that do forwarding to other resolvers. They simply can't do any other work. Or there are resolvers - like unbound - that (can) do the full resolution process of DNS. That one doesn't use unbound in resolving mode doesn't change the fact, that it is a resolver. Also it IS another process to simply forward a query to another DNS resolver (e.g. your providers DNS) OR actually querying it as an resolver and interpreting the response, checking DNSSEC and caching the result. That's how those services work.
That doesn't change the fact, that you can use a resolver like unbound in forwarding mode. AFAIR pfBlockerNG only states that you have to use the "DNS resolver" (aka unbound) as it only works together with unbound and it's API/python module, it isn't stated that you need it set to resolving itself. So if you absolutely need/want forwarding, switching it to forwarding mode shouldn't affect the outcome of DNS blocking by pfBlocker. You can always check that by querying it directly with a domain it should have blocked. It should return you with either the VIP you configured (10.10.10.x) or (better IMHO) reply with a DNS error/notfound when configured without the logging/reporting page.
Just wanted to add I was not here to argue about semantics but explain functionality as with DNS there's quite often consusion about what does what ;)
-
@JeGr, thank you very much for the excellent explanation :)
In other words, would you say I can leave my configuration as is since it achieves what I'm after? Or is there anything I should change? (please see screenshots above)
-
TL;DR: I for myself would configure logging in DNSBL to "disabled".
What it did in the past is that it redirected a query that was blocked to the VIP configured in pfB to a small site that stated "DNS address was blocked". Nice! But: with SSL everywhere and without doing something like SSL interception/injection and rolling out your own CA and installing it in every client, most connections today try to use HTTPS or SSL/TLS connections anyway. So you'd try e.g.
https://badsite.local
but even if pfBlocker's DNSBL blocks that site, the "logging" feature would then hand out the configured VIP to the client (e.g. 10.10.10.1). So your client would try to access the URL above with the URL resolved to 10.10.10.1. But as the mini-webserver that pfBlocker runs can't simply answer any domain via SSL - as it doesn't posess a certificate for it - you run into you typical browser SSL error message. And if you click that away you'll be greeted by the "this was blocked" page.
Sounds time consuming? Yes. Also it leaves your client "knowing" (incorrectly) that badsite.local is 10.10.10.1.
That process has 2 points, that I find "not that great":- You hand out false DNS records to your client (OK maybe acceptible) but that still takes a little time (in ms, sure, but it takes time) and make it try to access a site that only says "Nope!" - which again takes time for the browser to resolve, access, display the error and the site
- It makes client users "immune" to the 'dangers' of SSL/TLS interception and wrong/bad certificates. If you've seen the "blah blah SSL Error" of your browser that much, you simply dismiss it without further thought. So in case of a really bad site (phishing etc.) there's no "Oh wait, there is an error with the connection! Something smells fishy..." moment but a "Oh that again, I just have to dismiss it and the site will open anyway" effect.
Especially don't like the second one (for clients) and don't like the added overhead and time from the first one. That's why other projects like Pi-Hole report 0.0.0.0 as the DNS answer to a blocklisted domain query. That is even better as the old alias (localhost / 127.0.0.1 that many howtos recommend) because localhost will make the service at least once try a connection. And if you're a developer and have a local webservice running, that's not what you want ^^ Even if you're not it is another few ms added to a lookup that will fail. You want it to fail. So nowadays they use 0.0.0.0 -
https://discourse.pi-hole.net/t/use-0-0-0-0-instead-of-dns-ip-in-blocklists/5412 - as that will end up returning an error immediatly (in windows that's error_invalid_netname) without any connection attempt. So it's the fastes way (and 0.0.0.0 is valid in a DNS return) to get an "error" so your connection attempt will be blocked the fastest without any detours.\jens
-
@JeGr, thanks for your valuable insights, will certainly consider. If you're feeling bored, I changed the screenshots above to a single page so it's easier to view.
At any rate, dnsbl seems to work as expected for now.
Thanks everyone for your assistance.
-
From the DNS Resolver page in the pfSense manual:
DNS Query Forwarding:
Disabled by default. When enabled, unbound will use the system DNS servers from System > General Setup or those received from a dynamic WAN, rather than using the root servers directly.Just the confirmation I was looking for :)
