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

[msi]

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?

[cmb]

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

[johnpoz]

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

[cmb]

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

[johnpoz]

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.

[msi]

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>

[johnpoz]

"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.

[msi]

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).

[cmb]

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.

[msi]

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)?

[johnpoz]

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.