Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    25 Posts 4 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      s3b0
      last edited by

      Hi,

      I would like to know if there is a way to block DNS redirections(CNAME) for porn sites with pfsense(pfblockerng)? I notice that not all xxx rated pages are blocked even if there are on black/blocked list. The trick - to bypass blockers - that is used by those pages is CNAME with www at the beginning that points to A record with page.

      Example bellow(you can find more of these on web):

      s3b0@t14 ~ $ dig pornhub.com

; <<>> DiG 9.18.29 <<>> pornhub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30535
;; 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: 8 msec
;; SERVER: 192.168.2.1#53(192.168.2.1) (UDP)
;; WHEN: Sun Jan 19 09:23:50 CET 2025
;; MSG SIZE  rcvd: 56

s3b0@t14 ~ $ dig www.pornhub.com

; <<>> DiG 9.18.29 <<>> www.pornhub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35582
;; 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.        13709   IN      CNAME   pornhub.com.
pornhub.com.            13709   IN      A       66.254.114.41

;; Query time: 6 msec
;; SERVER: 192.168.2.1#53(192.168.2.1) (UDP)
;; WHEN: Sun Jan 19 09:23:54 CET 2025
;; MSG SIZE  rcvd: 74

      10.10.10.1: is virtual address of pfblockerng web server.
      192.168.2.1: is my gateway with pfsense.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Do you have TLD enabled in DNS-BL? That should catch that as a subdomain. It wouldn't catch something using a completely different cname though.

        S 1 Reply Last reply Reply Quote 0
        • S
          s3b0 @stephenw10
          last edited by

          @stephenw10
          cc1ba00d-ea6d-4671-8cea-89cdd15536ea-image.png

          I've enabled Wildcard Blocking - still pfblockerng allows CNAME redirect.

          1 Reply Last reply Reply Quote 0
          • S
            s3b0
            last edited by s3b0

            Weird, right after unbound restart ip is pointing to my vip of pfblockerng(10.10.10.1) but second query returns real ip.

            3b0@t14 ~ $ dig www.pornhub.com
;; communications error to 192.168.2.1#53: timed out
;; communications error to 192.168.2.1#53: timed out

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

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

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

;; Query time: 1294 msec
;; SERVER: 192.168.2.1#53(192.168.2.1) (UDP)
;; WHEN: Tue Jan 21 10:19:52 CET 2025
;; MSG SIZE  rcvd: 60

s3b0@t14 ~ $ dig www.pornhub.com

; <<>> DiG 9.18.29 <<>> www.pornhub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30580
;; 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.        14398   IN      CNAME   pornhub.com.
pornhub.com.            14398   IN      A       66.254.114.41

;; Query time: 5 msec
;; SERVER: 192.168.2.1#53(192.168.2.1) (UDP)
;; WHEN: Tue Jan 21 10:19:54 CET 2025
;; MSG SIZE  rcvd: 74

            What is going on?

            M GertjanG stephenw10S 3 Replies Last reply Reply Quote 0
            • M
              mcury @s3b0
              last edited by

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

              What is going on?

              you need to enable Wildcard Blocking (TLD)

              dead on arrival, nowhere to be found.

              S 1 Reply Last reply Reply Quote 0
              • S
                s3b0 @mcury
                last edited by

                @mcury it's enabled already

                M 1 Reply Last reply Reply Quote 0
                • M
                  mcury @s3b0
                  last edited by

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

                  @mcury it's enabled already

                  run a force update after enabling it

                  dead on arrival, nowhere to be found.

                  1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @s3b0
                    last edited by Gertjan

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

                    What is going on?

                    What have you listed/set here :

                    df02f136-e599-4735-8e95-afac069d8ffd-image.png

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator @s3b0
                      last edited by

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

                      but second query returns real ip.

                      Hmm, that is weird. Yes, try a forced update. Enabling TLD can created a large reload time.

                      Otherwise I would bump up the logging level in Unbound and run the queries again to see what's happening.

                      But also check the DNS servers configured on the client. If you have more than one it could be querying them alternately and the other one is not filtered.

                      S 1 Reply Last reply Reply Quote 0
                      • S
                        s3b0
                        last edited by s3b0

                        @Gertjan
                        My settings:
                        4823d62d-7078-467d-a4a8-233b295df809-image.png

                        GertjanG 1 Reply Last reply Reply Quote 0
                        • S
                          s3b0 @stephenw10
                          last edited by

                          @stephenw10
                          DNSLBL is reloaded - i always do it if i change its behavior

                          1 Reply Last reply Reply Quote 0
                          • GertjanG
                            Gertjan @s3b0
                            last edited by

                            @s3b0

                            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 :

                            76101dd9-632b-4c55-9b8a-700076e48005-image.png

                            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.

                            No "help me" PM's please. Use the forum, the community will thank you.
                            Edit : and where are the logs ??

                            S 1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • S
                                s3b0 @Gertjan
                                last edited by

                                @Gertjan switched to:
                                78129f9d-0678-4b0d-a460-a98eefaa90c4-image.png

                                same effect :(

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  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.

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    s3b0 @stephenw10
                                    last edited by 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.

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      s3b0
                                      last edited by 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
                                      4dffe770-4fe3-4f5b-ab64-032dfcca1d01-image.png
                                      FW rules(LAN tab):
                                      cd595e90-865d-4c58-bd5c-d0ee3d87bee3-image.png

                                      GertjanG 1 Reply Last reply Reply Quote 0
                                      • GertjanG
                                        Gertjan @s3b0
                                        last edited by

                                        @s3b0

                                        This one :

                                        14793e92-d582-4e3c-94bf-5e25b312c340-image.png

                                        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.

                                        No "help me" PM's please. Use the forum, the community will thank you.
                                        Edit : and where are the logs ??

                                        S 1 Reply Last reply Reply Quote 0
                                        • S
                                          s3b0 @Gertjan
                                          last edited by

                                          @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 :(

                                          GertjanG 1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            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.

                                            S 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.