Block xxx rated pages redirections (CNAME -> A) - pfblockerng

Gertjan

In that case, when you see this :

@s3b0 said in Block xxx rated pages redirections (CNAME -> A) - pfblockerng:

;; communications error to 192.168.2.1#53: timed out
;; communications error to 192.168.2.1#53: timed out

which says : dig wanted to contact "192.168.2.1" (== pfSense unbound) but wasn't avaible, so ok ... more DNS servers are available (not there by default, but you've added them), so it took 208.68.222.222 or 208.67.220.220 etc.
And the DNS request against one of them worked out just fine, p#rn.com was resolved.

Exactly what you told your pfSense :

I guess you get it by now : if you want your DNS request to be filtered by pfBockerng, they have to be handled by unbound (only) who passes them through pfBlockerng. If this circuit can get bypassed, filtering stops working.

stephenw10

Ah good catch!. But it still shows the server as being 192.168.2.1 when returns the real IP address.

s3b0

@Gertjan switched to:

same effect :(

stephenw10

Hmm, must be something in your config I can't replicate that here:

[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig www.doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig www.doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig www.doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig www.doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig doubleclick.com +short
10.10.10.1
[24.11-RELEASE][admin@fw1.stevew.lan]/root: dig doubleclick.com +short
10.10.10.1

Where are you testing from? I had assumed it was from pfSense directly but now I look it can't be since it's not using localhost.

So I still think it's either the client using a different DNS server directly or something cached at the client.

s3b0

@stephenw10 i have same results on pfsense

[2.7.2-RELEASE][root@gateway.home]/root: dig www.pornhub.com

; <<>> DiG 9.18.19 <<>> www.pornhub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63322
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;www.pornhub.com.               IN      A

;; ANSWER SECTION:
www.pornhub.com.        11712   IN      CNAME   pornhub.com.
pornhub.com.            11712   IN      A       66.254.114.41

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Jan 22 12:34:17 CET 2025
;; MSG SIZE  rcvd: 74

[2.7.2-RELEASE][root@gateway.home]/root: dig pornhub.com

; <<>> DiG 9.18.19 <<>> pornhub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44379
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;pornhub.com.                   IN      A

;; ANSWER SECTION:
pornhub.com.            60      IN      A       10.10.10.1

;; Query time: 14 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Jan 22 12:36:22 CET 2025
;; MSG SIZE  rcvd: 56

And still: after restarting unbound url with www at the begging returns 10.10.10.1 and second try returns real ip ... have no clue why.

s3b0

Maybe i has something to do with my rules - don't know just asking more wiser users ;)

I blocked traffic to other dnses than my by fw rule and NAT forwarding like so:
NAT

FW rules(LAN tab):

Gertjan

@s3b0

This one :

and related firewall rule doesn't need UDP.
TLS is always TCP.

If you do not set up DNS over TLS on port 853 on your LAN clients, it won't get used.
Just look at the related firewall rule of that NAT rule : the counters will always stay at "0/0" = the rule never applied.

And even better : 853 uses TLS, so a certificate is used.
Let say you do DNS over TLS using port 853 to 1.1.1.1. Your rule will match, and redirect TLS traffic to 127.0.0.1.
The server that replies ( aha : unbound on its 853 port !) will it have a certificate that says it's "I am one.one.one.one !" ? Nope. Impossible. You are not 1.1.1.1 (one.one.one.one) so the very first ground rule of the TLS connection is already broken, it will probably fail.
So, don't bother NATting that DNS TLS traffic. If you don't want it, block it. This will signal the LAN client that DNS over TLS isn't available It will fall back to classic UDP/TCP traffic over port 53.

s3b0

@Gertjan thx, I just corrected those settings (NAT removed for Dns over TLS, and fw rule changed to block that traffic).
But issue with CNAME still unsolved :(

stephenw10

Did you try turning up the Unbound logging level and checking what it's actually seeing yet?

I suspect it's not seeing that second request at all for some reason.

s3b0

@stephenw10 i think that unbound works as expected(?):

info from pfblockerng unified report:

Gertjan

@s3b0 said in Block xxx rated pages redirections (CNAME -> A) - pfblockerng:

But issue with CNAME still unsolved :(

AS I don't have DNSBL that blocks this porn site, I activated the heavy artillery (regex) :

^pornhub.* #Comment-line-1
^www.pornhub.* #Comment-Line-2

and now :

same thing for the the domain without "www."

Still a (small) problem, for me, as suddenly "10.10.10.1" (The default web server "You are blocked" IP is returned, and not the 0.0.0.0 == NULL logging and blocking).

From none of my device I can access p#rnhub anymore.
And that's a problem for me, as I have a hotel here (kids are not my problem, they don't pay the bills here)

dit :
Intercepted :

stephenw10

Hmm, so you are seeing all queries reach Unbound and be answered? But it just looks like the TLD option fails to match the list on the repeat query....

s3b0

@stephenw10 i think that is the problem here - maybe bug?

s3b0

@Gertjan as a last resort i will enable that ;). If i would be owner of hotel i also would not enable that ;)