DNS resolver in forwarding mode doesn't give answer for private IPs
-
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 -
in the advanced section if you check to disable rebinding checks those entries will be removed from the unbound.conf file
-
Or yeah completely disable that. It's safer to just add the domain(s) in question as exclusions where that's practical.
-
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.
-
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>
-
"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.
-
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). -
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.
-
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)?
-
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.