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

    DNS query to RBL blacklists return no answer

    DHCP and DNS
    6
    24
    2.4k
    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.
    • M
      Milan
      last edited by

      Hello everyone.
      After update from 2.4.2 to 2.4.5 query to RBL dns blacklists return no answer.

      I use dns resolver (unbound) with enable forwarding mode query to Google public dns servers (pfsense local ip 192.168.100.2.).

      Testing query on local server machine (dns resolver set to pfsense).

      dig 2.0.0.127.b.barracudacentral.org         
      
      ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> 2.0.0.127.b.barracudacentral.org
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;2.0.0.127.b.barracudacentral.org. IN	A
      
      ;; Query time: 44 msec
      ;; SERVER: 192.168.100.2#53(192.168.100.2)
      ;; WHEN: Sat Apr 18 11:32:37 CEST 2020
      ;; MSG SIZE  rcvd: 61
      

      result dns query direct to google

      dig @8.8.8.8 2.0.0.127.b.barracudacentral.org
      
      ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @8.8.8.8 2.0.0.127.b.barracudacentral.org
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32216
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;2.0.0.127.b.barracudacentral.org. IN	A
      
      ;; ANSWER SECTION:
      2.0.0.127.b.barracudacentral.org. 22 IN	A	127.0.0.2
      
      ;; Query time: 21 msec
      ;; SERVER: 8.8.8.8#53(8.8.8.8)
      ;; WHEN: Sat Apr 18 11:32:43 CEST 2020
      ;; MSG SIZE  rcvd: 77
      

      result with disabled forwarding mode in pfsense

      dig 2.0.0.127.b.barracudacentral.org         
      
      ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> 2.0.0.127.b.barracudacentral.org
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40069
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;2.0.0.127.b.barracudacentral.org. IN	A
      
      ;; AUTHORITY SECTION:
      b.barracudacentral.org.	900	IN	NS	blacklist-ns-az2.bci.aws.cudaops.com.
      b.barracudacentral.org.	900	IN	NS	blacklist-ns-az3.bci.aws.cudaops.com.
      b.barracudacentral.org.	900	IN	NS	blacklist-ns-az1.bci.aws.cudaops.com.
      
      ;; Query time: 450 msec
      ;; SERVER: 192.168.100.2#53(192.168.100.2)
      ;; WHEN: Sat Apr 18 11:01:13 CEST 2020
      ;; MSG SIZE  rcvd: 173
      

      Any advice? Thanks!

      1 Reply Last reply Reply Quote 0
      • D
        digdug3
        last edited by

        Hi Milan,

        I'm having the same problem, did you find a way to resolve this?

        1 Reply Last reply Reply Quote 0
        • M
          Milan
          last edited by

          Hi,
          I did not find... Unbound has a issue with resolving rDNS. So far I use dns forwarder (dnsmasq).

          D 1 Reply Last reply Reply Quote 0
          • D
            digdug3 @Milan
            last edited by

            @Milan Thanks for the response. Do you also have issues with TXT records?

            1 Reply Last reply Reply Quote 0
            • D
              digdug3
              last edited by

              Turned off pfBlockerNG, all non-default settings still the same problem, also when enabling DNS Query Forwarding to 8.8.8.8 or 9.9.9.9

              A direct dig to 9.9.9.9 gives an answer

              dig @9.9.9.9 81.173.198.114.b.barracudacentral.org
              
              ; <<>> DiG 9.14.12 <<>> @9.9.9.9 81.173.198.114.b.barracudacentral.org
              ; (1 server found)
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28686
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
              
              ;; OPT PSEUDOSECTION:
              ; EDNS: version: 0, flags:; udp: 4096
              ;; QUESTION SECTION:
              ;81.173.198.114.b.barracudacentral.org. IN A
              
              ;; ANSWER SECTION:
              81.173.198.114.b.barracudacentral.org. 900 IN A 127.0.0.2
              
              ;; Query time: 217 msec
              ;; SERVER: 9.9.9.9#53(9.9.9.9)
              ;; WHEN: Wed Jul 01 17:36:06 CEST 2020
              ;; MSG SIZE  rcvd: 82
              

              and v2.4.5-1 Unbound (no answer):

              dig @127.0.0.1 81.173.198.114.b.barracudacentral.org
              
              ; <<>> DiG 9.14.12 <<>> @127.0.0.1 81.173.198.114.b.barracudacentral.org
              ; (1 server found)
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12449
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
              
              ;; OPT PSEUDOSECTION:
              ; EDNS: version: 0, flags:; udp: 4096
              ;; QUESTION SECTION:
              ;81.173.198.114.b.barracudacentral.org. IN A
              
              ;; AUTHORITY SECTION:
              b.barracudacentral.org. 777     IN      NS      blacklist-ns-az1.bci.aws.cudaops.com.
              b.barracudacentral.org. 777     IN      NS      blacklist-ns-az2.bci.aws.cudaops.com.
              b.barracudacentral.org. 777     IN      NS      blacklist-ns-az3.bci.aws.cudaops.com.
              
              ;; Query time: 0 msec
              ;; SERVER: 127.0.0.1#53(127.0.0.1)
              ;; WHEN: Wed Jul 01 17:36:19 CEST 2020
              ;; MSG SIZE  rcvd: 178
              
              

              This looks like a bug.

              1 Reply Last reply Reply Quote 0
              • D
                digdug3
                last edited by digdug3

                Ok, fixed it.

                Looks like pfSense 2.4.5-p1 now sets the DNS Rebinding Attack in the Unbound config.
                This will remove any IP address with 127.0.0.0/8 responses (RBL's).

                Go to System -> Advanced and check "Disable DNS Rebinding checks"

                Then go to Services -> DNS Resolver and if you still want some protection click "Display Custom Options" and add:

                private-address: 127.0.0.1/32
                private-address: 10.0.0.0/8
                private-address: ::ffff:a00:0/104
                private-address: 172.16.0.0/12
                private-address: ::ffff:ac10:0/108
                private-address: 169.254.0.0/16
                private-address: ::ffff:a9fe:0/112
                private-address: 192.168.0.0/16
                private-address: ::ffff:c0a8:0/112
                private-address: fd00::/8
                private-address: fe80::/10
                

                Maybe someone else has a better approach. If not then it would be nice if there was an option to disable the private-address "127.0.0.0/8" from this DNS-Rebinding check list.
                Edit: Fixed typo in version and added 127.0.0.1/32 I have not seen that address being used by any RBL response.

                N 1 Reply Last reply Reply Quote 1
                • N
                  netblues @digdug3
                  last edited by netblues

                  @digdug3 Yes, this fixes the issue. However is a workaround. A proper bug report should be filed. Well done

                  1 Reply Last reply Reply Quote 0
                  • D
                    digdug3
                    last edited by

                    @Milan you can file a bug report at https://redmine.pfsense.org/projects/pfsense/issues and refer to this page.
                    @netblues It's not 100% a bug, when you want to proper block DNS Rebinding Attacks, 127.0.0.0/8 should also be in the list according to https://en.wikipedia.org/wiki/DNS_rebinding

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

                      Hello!

                      https://redmine.pfsense.org/issues/10685

                      John

                      Lex parsimoniae

                      N 1 Reply Last reply Reply Quote 0
                      • N
                        netblues @serbus
                        last edited by netblues

                        Well, the workaround suggests to put specific sites to allow 127.0.0.0/8 replies.
                        Since dns rbl blacklists are used exclusively by mail servers, often it falls under quite different administrative domains, and in most cases it will either pass undetected, or public dns's would be configured as a workaround.

                        On the other hand, dnsrbl tend to use various servers, and keeping that in sync with pf allow settings is an issue.
                        How about an rbl exclude based on client ip? (and only for 127.0.0.0/8 replies)?
                        As a setting in advanced pf configuration.

                        1 Reply Last reply Reply Quote 0
                        • D
                          digdug3
                          last edited by

                          @serbus Thank you for the info, did not see that bug report before. But adding an extending/changing list of rbl servers to the allow list is not user friendly. We user multiple rbl lists to check against.
                          Removing 127.0.0.0/8 like in previous versions of pfSense is in my option a better approach. I already added only 127.0.0.1 as that could be the best between the recent changes. Also if we want to be "complete" ::1 should also be listed (and is not in the current default of pfSense).
                          @netblues I will have to dig deeper into Unbound's configuration options. Excluding on client ip could be another option and better approach. Another question of course is do you really need the full 127.0.0.0/8 blocked or only 127.0.0.1/32?

                          N 1 Reply Last reply Reply Quote 0
                          • B
                            biggsy
                            last edited by

                            May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/

                            N 1 Reply Last reply Reply Quote 0
                            • N
                              netblues @digdug3
                              last edited by

                              @digdug3 Unfortunately 127.0.0.0/8 is needed.
                              see here for details
                              https://www.spamhaus.org/faq/section/Spamhaus%20DBL#291

                              1 Reply Last reply Reply Quote 0
                              • N
                                netblues @biggsy
                                last edited by

                                @biggsy said in DNS query to RBL blacklists return no answer:

                                May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/

                                Well, its not that they block it, they just rate limit it. (which leads to the same effect)
                                In order to utilize any dnsbl practically means to use your own dns quering root servers.
                                Anything else tends to be problematic.
                                (thus the need to have pfsense do the job.)

                                1 Reply Last reply Reply Quote 0
                                • B
                                  biggsy
                                  last edited by

                                  @netblues
                                  I don't think "rate limit" really describes it. In the link provided:
                                  "Spamhaus does not permit queries from such public DNS resolvers."

                                  If you have pfSense use those public resolvers, on behalf of your mail server, you risk getting a 127.255.255.254 response. Better to have your mail server run its own resolver.

                                  N 1 Reply Last reply Reply Quote 0
                                  • N
                                    netblues @biggsy
                                    last edited by

                                    @biggsy I was referring to others too, but anyways, the problem remains the same
                                    No forwarders can be used for dnsbl lookups in practice.

                                    From a security point of view its better to have pf do the lookups instead of allowing outbound dns lookups to root servers for the mailserver.

                                    Pushing this to the limit, forwarders for speedier responses and root server lookups for dnsbl is the best. (as a feature)

                                    1 Reply Last reply Reply Quote 0
                                    • D
                                      digdug3
                                      last edited by

                                      @jimp Accoring to the bugrequest #10685 at redmine (https://redmine.pfsense.org/issues/10685) pfSense should only block 127.0.0.1 when "DNS Rebinding" is enabled, but now it blocks the whole 127.0.0.0/8 subnet

                                      " Status changed from New to Not a Bug

                                      This is due to the change in #9708 on 2.4.5 -- 127.0.0.1 is considered a private result now so you will need to tell the DNS Resolver it's OK to receive private address results from that domain.

                                      https://docs.netgate.com/pfsense/en/latest/dns/dns-rebinding-protections.html#dns-resolver-unbound

                                      If you still have issues, post on the forum."

                                      This blocks resolving of dns blacklists. Is this a bug? See: https://forum.netgate.com/topic/152671/dns-query-to-rbl-blacklists-return-no-answer/16

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

                                        Hello!

                                        You should be able to edit unbound.inc and either modify or remove the :

                                        private-address: 127.0.0.0/8

                                        line.

                                        You would good until the next reinstall or upgrade.

                                        John

                                        Lex parsimoniae

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          digdug3
                                          last edited by

                                          Next upgrade that file will probably be overwritten and I think it should/could be:
                                          private-address: 127.0.0.1/32

                                          N 1 Reply Last reply Reply Quote 0
                                          • N
                                            netblues @digdug3
                                            last edited by

                                            @digdug3 And all these

                                            What do the 127...* Return Codes mean?
                                            Spamhaus uses this general convention for return codes:

                                            Return Code Description
                                            127.0.0.0/24 Spamhaus IP Blocklists
                                            127.0.1.0/24 Spamhaus Domain Blocklists
                                            127.0.2.0/24 Spamhaus Zero Reputation Domains list
                                            127.255.255.0/24 ERRORS (not implying a "listed" response)

                                            Currently used return codes for Spamhaus public IP zones:

                                            Return Code Zone Description
                                            127.0.0.2 SBL Spamhaus SBL Data
                                            127.0.0.3 SBL Spamhaus SBL CSS Data
                                            127.0.0.4 XBL CBL Data
                                            127.0.0.9 SBL Spamhaus DROP/EDROP Data (in addition to 127.0.0.2, since 01-Jun-2016)
                                            127.0.0.10 PBL ISP Maintained
                                            127.0.0.11 PBL Spamhaus Maintained

                                            127.0.0.5-7 are allocated to XBL for possible future use; 127.0.0.8 is allocated to SBL for possible future use.

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