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

    DNS resolver in forwarding mode doesn't give answer for private IPs

    Scheduled Pinned Locked Moved DHCP and DNS
    11 Posts 3 Posters 5.5k 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.
    • M
      msi
      last edited by

      Hi there

      So here is the situation: pfSense was using dnsmasq and was set to forward to a remote DNS server that resolves internal host names now I wanted to get a grip and move to unbound since that's what I already used as secondary cache nameserver on a Linux box. The problem is due to the situation this setup is in, the remote DNS is on the WAN side and it resolves also hostnames having IPv4 adresses (yes it's kind of a double NAT, pfSense-internally its within 192.168/16 where the outer side is in the 10/8 RFC1918 adress space).

      I asked myself why it just worked with the unbound on the Linux box but not on pfSense. The point is pfSense developers do a very good job at giving us a solid and tightly secured unbound config (props on that!). However in this case it hurt me and I'm looking to properly work around without breaking the pfSense management side.

      The offending config entry in unbound.conf I don't have on the other nameserver is private-address: 10.0.0.0/8. Once that entry is absent, unbound will resolve things properly. However at each change in the config or a service restart unbound.conf gets regenerated and the thing gets added back.

      I've tried to skim through the config pages of the DNS resolver on pfSense, but nowhere could I find how to make it not write that block into the config.
      Is there a right(TM) way to let it know to resolve such host names. Similar things can be done on the firewall side if you want to allow RFC1918 network traffic from the WAN side.

      And no, I can just do some overrides since the one domain in question is an AD with a ton of subdomains, additionnaly it resolves a heck a lot of (also) private IPs from peer offices using private IP adresses which are resolved through these nameservers. Maybe someone got an idea on how to work around this within pfSense?

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        Just add that domain as an exception to the DNS rebinding protections (which will cover all its subdomains).
        https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

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

          in the advanced section if you check to disable rebinding checks those entries will be removed from the unbound.conf file

          disablerebind.png_thumb
          disablerebind.png

          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 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Or yeah completely disable that. It's safer to just add the domain(s) in question as exclusions where that's practical.

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

              I have to assume he is forwarding since he is resolving rfc1918 in the first place.  Who wold store their AD dns in public dns?  And he says he is not using overrides

              So any rebinding protection should be happening at his upstream name server..  So seems easier to uncheck vs having to worry about whatever domains you might be resolving from the local network he is asking.

              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 24.11 | Lab VMs 2.8, 24.11

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

                Hey - thanks. A clear case of looking for the right thing but in the wrong place…

                Here is what I ended up with for now:
                  * Copy the private-address blocks as present in the pfSense standard unbound.conf
                  * Disable DNS rebinding protection
                  * EDIT: I wanted to re-add private-address except for 10.0.0.0/8 so I'd have retained most of the rebinding protection as is.

                -> pfSense generates unbound.conf as such as the custom options are put after the forward-zone statements.
                The config is considered valid 'private-address' definitions are in the config just right before forward-zone.
                If they are after forward-zone definitions unbound-checkconf won't like it and unbound won't start.

                cmb: Would it be possible in an future version to insert the custom block somewhere before the forward-zone definition in the config instead of how it is done in 2.2.6?
                (if you think that might be possible I might file a bug then and see what I can do)

                And on that question by johnpoz:

                Who wold store their AD dns in public dns?  And he says he is not using overrides

                The design of that network is as follows:

                <public wan="" ip(s)="">|
                <network 8="" with="" several="" peers="" (10.0.0.0="" space)="">-> Here is the said DNS resolver we have to forward to
                          |
                <pfsense>|
                <client 16="" networks="" with="" 192.168.0.0="">It is an ugly situation which is the result of the decisions made by those managing the IP address space of 10.0.0.0/8 that they don't give use more subnets than we need client IPs for enduser wireless devices mostly. The result is a double NAT which thankfully works for us, but yes I totaly agree that it is not great.

                The mentioned DNS resolver pfSense forwards is in 10.0.0.0/8 but also resolves essentials hostnames only present part of this address space which are needed by systems behind pfSense.
                This server resolves not only the AD domain but a heck a lot of other internal domains.

                Edit: Mention the config issue and improve spelling</client></pfsense></network></public>

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

                  "but a heck a lot of other internal domains."

                  Exactly so that would make it difficult to do exceptions for all those domains.

                  Curious why you don't just use dnsmasq if all your doing is forwarding anyway.

                  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 24.11 | Lab VMs 2.8, 24.11

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

                    Good question. Since I had to touch the system for some other changes anyway in preparation for a migration, I remembered that 2.2 didn't enable dnsmasq by default on new setups, this box was updated step by step with each release since 2.1. Back then we only had dnsmasq. I haven't seen a word in release notes that it is officially going to be deprecated, maybe it will? I haven't seen where the dnsmasq vs. unbound discussion is going with 2.3.

                    Another, more a personal choice: I've been using unbound on the secondary nameserver and also on other projects with good results.
                    It has worked very well and I'm more familiar with the options (even though pfSense hides that pretty well from me on the firewall).

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      I kind of doubt we'll retain both dnsmasq and unbound forever, but there are no plans in the immediate future to remove either of them. Each has capabilities the other does not. Both will remain as is for 2.3.x at a minimum.

                      You should be able to disable DNS rebinding protection and manually add private-address config if you want.

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

                        cmb, thanks!

                        What about the issue I mentioned about position of custom parameters they get inserted after forward-zone which doesn't make it possible to re-add privat-address definitions right now (can confirm on 2.2.6)?

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

                          did you put server: in the advanced option box above your private settings?

                          My guess is this what your forgetting to do if you want to add them back in.

                          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 24.11 | Lab VMs 2.8, 24.11

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