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

    Strange resolver problem

    Scheduled Pinned Locked Moved DHCP and DNS
    7 Posts 3 Posters 1.2k 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.
    • R Offline
      rubenc
      last edited by

      Hi,

      I'm having a strange problem. DNS Resolver service is on, and everything works. Well, almost everything.

      Any query resolving to an IP belonging to any of the LAN addressings, is returned empty.

      Example:

      fibra.xxx.xxx resolves to 81.47.17.21 (public IP answer)
      sonar.xxx.xxx resolves to 172.26.10.190 (private IP answer)
      test.xxx.xxx resolves to 172.26.3.5 (private IP answer)

      172.26.10.0/24 is a /24 in an OPT interface
      172.26.3.5 is a /24 in a VLAN interface

      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig fibra.xxx.xxx 
      
      ; <<>> DiG 9.10.4-P2 <<>> fibra.xxx.xxx
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31824
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;fibra.xxx.xxx.           IN      A
      
      ;; ANSWER SECTION:
      fibra.xxx.xxx.    45      IN      A       81.47.17.21
      
      ;; AUTHORITY SECTION:
      xxx.xxx.          171269  IN      NS      ns-1257.awsdns-29.org.
      xxx.xxx.          171269  IN      NS      ns-1647.awsdns-13.co.uk.
      xxx.xxx.          171269  IN      NS      ns-474.awsdns-59.com.
      xxx.xxx.          171269  IN      NS      ns-783.awsdns-33.net.
      
      ;; Query time: 0 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1)
      ;; WHEN: Mon Oct 24 19:04:31 CEST 2016
      ;; MSG SIZE  rcvd: 201
      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig sonar.xxx.xxx  
      
      ; <<>> DiG 9.10.4-P2 <<>> sonar.xxx.xxx
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26372
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;sonar.xxx.xxx.           IN      A
      
      ;; AUTHORITY SECTION:
      xxx.xxx.          171263  IN      NS      ns-1257.awsdns-29.org.
      xxx.xxx.          171263  IN      NS      ns-1647.awsdns-13.co.uk.
      xxx.xxx.          171263  IN      NS      ns-474.awsdns-59.com.
      xxx.xxx.          171263  IN      NS      ns-783.awsdns-33.net.
      
      ;; Query time: 0 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1)
      ;; WHEN: Mon Oct 24 19:04:37 CEST 2016
      ;; MSG SIZE  rcvd: 185
      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig test.xxx.xxx     
      
      ; <<>> DiG 9.10.4-P2 <<>> test.xxx.xxx
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45889
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;test.xxx.xxx.            IN      A
      
      ;; AUTHORITY SECTION:
      xxx.xxx.          171258  IN      NS      ns-1257.awsdns-29.org.
      xxx.xxx.          171258  IN      NS      ns-1647.awsdns-13.co.uk.
      xxx.xxx.          171258  IN      NS      ns-474.awsdns-59.com.
      xxx.xxx.          171258  IN      NS      ns-783.awsdns-33.net.
      
      ;; Query time: 122 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1)
      ;; WHEN: Mon Oct 24 19:04:42 CEST 2016
      ;; MSG SIZE  rcvd: 184
      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: 
      
      

      If I use G's resolvers:

      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig @8.8.8.8 sonar.xxx.xxx
      
      ; <<>> DiG 9.10.4-P2 <<>> @8.8.8.8 sonar.xxx.xxx
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 736
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;sonar.xxx.xxx.           IN      A
      
      ;; ANSWER SECTION:
      sonar.xxx.xxx.    299     IN      A       172.26.10.190
      
      ;; Query time: 52 msec
      ;; SERVER: 8.8.8.8#53(8.8.8.8)
      ;; WHEN: Mon Oct 24 19:05:28 CEST 2016
      ;; MSG SIZE  rcvd: 64
      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig @8.8.8.8 test.xxx.xxx
      
      ; <<>> DiG 9.10.4-P2 <<>> @8.8.8.8 test.xxx.xxx
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20296
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;test.xxx.xxx.            IN      A
      
      ;; ANSWER SECTION:
      test.xxx.xxx.     299     IN      A       172.26.3.5
      
      ;; Query time: 49 msec
      ;; SERVER: 8.8.8.8#53(8.8.8.8)
      ;; WHEN: Mon Oct 24 19:05:33 CEST 2016
      ;; MSG SIZE  rcvd: 63
      
      [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: 
      
      

      Any thoughts? I'm doing the DNS queries for this question from the firewall itself, but it happens the same no matter from where I make the queries.

      Thanks,

      Rubén.

      Hardware: SC1935 | WAN: em (PCIe) | LAN: bge (onboard) | RAM: 2Gb
      2.0-RC2-IPv6 (i386)
      built on Sat May 21 21:38:32 EDT 2011

      1 Reply Last reply Reply Quote 0
      • jimpJ Offline
        jimp Rebel Alliance Developer Netgate
        last edited by

        That is the default behavior by design. Accepting private IP address responses from public DNS servers allows DNS Rebinding attacks, so those responses are dropped.

        You can disable or work around this behavior as needed: https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • R Offline
          rubenc
          last edited by

          ;) Thanks a lot sir.

          Rubén.

          Hardware: SC1935 | WAN: em (PCIe) | LAN: bge (onboard) | RAM: 2Gb
          2.0-RC2-IPv6 (i386)
          built on Sat May 21 21:38:32 EDT 2011

          1 Reply Last reply Reply Quote 0
          • johnpozJ Offline
            johnpoz LAYER 8 Global Moderator
            last edited by

            Having some public NS respond with private IP is BORKED.. the proper solution would not to return rfc1918 space from a public NS.

            Now if the NS returning it is not really public and only upstream from unbound running on pfsense, then sure you can work around this by disable of rebind or setting private domain.

            But if this NS is on the public internet an anyone on the internet can query it - returning rfc1918 is borked.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

            1 Reply Last reply Reply Quote 0
            • R Offline
              rubenc
              last edited by

              @johnpoz:

              Having some public NS respond with private IP is BORKED.. the proper solution would not to return rfc1918 space from a public NS.

              Now if the NS returning it is not really public and only upstream from unbound running on pfsense, then sure you can work around this by disable of rebind or setting private domain.

              But if this NS is on the public internet an anyone on the internet can query it - returning rfc1918 is borked.

              Well, that's a matter of oppinion, configuration and usage. We have a pair of domains we only use for internal apps and their entries are never seen/used outside our development/staging environments. Yes, I could set up private resolvers, but it's not worth the effort.

              Rubén.

              Hardware: SC1935 | WAN: em (PCIe) | LAN: bge (onboard) | RAM: 2Gb
              2.0-RC2-IPv6 (i386)
              built on Sat May 21 21:38:32 EDT 2011

              1 Reply Last reply Reply Quote 0
              • johnpozJ Offline
                johnpoz LAYER 8 Global Moderator
                last edited by

                The opinion would be that of everyone in the field..  Public dns is not for rfc1918 space..  As mentioned this is how rebinding attacks happen!

                https://tools.ietf.org/html/draft-ietf-dnsop-dontpublish-unreachable-03

                You sure and the hell can not do PTR for rfc1918 space in the public space..

                Not worth the effort??  And you wonder why you have problems..

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                1 Reply Last reply Reply Quote 0
                • R Offline
                  rubenc
                  last edited by

                  Well, I was coming from a previous (2.1) pfsense version and didn't have the time to review all changes in detail. Anyway you guys are right, thanks.

                  Rubén.

                  Hardware: SC1935 | WAN: em (PCIe) | LAN: bge (onboard) | RAM: 2Gb
                  2.0-RC2-IPv6 (i386)
                  built on Sat May 21 21:38:32 EDT 2011

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