DNS Resolver domain override issue for just one client in the same network
-
Here's some logs from 192.168.20.1:
Oct 5 23:48:39 unbound 77902 [77902:3] info: validator operate: query pfsense.home.arpa. A IN Oct 5 23:48:39 unbound 77902 [77902:3] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone Oct 5 23:48:39 unbound 77902 [77902:3] debug: return error response SERVFAIL Oct 5 23:48:39 unbound 77902 [77902:3] debug: configured stub or forward servers failed -- returning SERVFAIL Oct 5 23:48:39 unbound 77902 [77902:3] info: processQueryTargets: pfsense.home.arpa. A IN Oct 5 23:48:39 unbound 77902 [77902:3] info: error sending query to auth server 192.168.10.1 port 53 Oct 5 23:48:39 unbound 77902 [77902:3] notice: remote address is 192.168.10.1 port 53 Oct 5 23:48:39 unbound 77902 [77902:3] notice: sendto failed: Can't assign requested address Oct 5 23:48:39 unbound 77902 [77902:3] debug: sending to target: <home.arpa.> 192.168.10.1#53 Oct 5 23:48:39 unbound 77902 [77902:3] info: sending query: pfsense.home.arpa. A IN -
OH WAIT! It looks like even A is not working. A is pihole in this case and I forgot that I had configured pihole to forward requests directly to 192.168.10.1 for home.arpa, therefore bypassing the DNS resolver in pfsense. So at least now I know that the behavior is consistent for all 192.168.20.0/24 clients. The pfsense DNS resolver is definitely acting up at this point.
-
One important question here. When unbound queries a request for the domain override to the destination DNS server, what source IP does it use? localhost? Because I might need to re-enable this SNAT rule to fix this:
-
Ok, so re-enabling that SNAT rule on both sides and adding the WIREGUARD network to the DNS resolver access list on both sides fixed the problem.
-
@kevindd992002 said in DNS Resolver domain override issue for just one client in the same network:
behavior is consistent for all 192.168.20.0/24 clients.
That makes more sense.. Well depends on what natting your doing or not doing.. And yes through any forward with an domain override you can run into 2 issues.
if answer comesback as rfc1918 it would be considered a rebind - so you need to make sure the domain is set as private in the unbound doing the query.
On the other end where your forwarding too, that unbound ACL would have to be setup to allow the query from this remote network.. Sure you could work around the ACL issue with a sourcenat on that site, but better would be is just update the ACL.
-
@johnpoz said in DNS Resolver domain override issue for just one client in the same network:
@kevindd992002 said in DNS Resolver domain override issue for just one client in the same network:
behavior is consistent for all 192.168.20.0/24 clients.
That makes more sense.. Well depends on what natting your doing or not doing.. And yes through any forward with an domain override you can run into 2 issues.
if answer comesback as rfc1918 it would be considered a rebind - so you need to make sure the domain is set as private in the unbound doing the query.
On the other end where your forwarding too, that unbound ACL would have to be setup to allow the query from this remote network.. Sure you could work around the ACL issue with a sourcenat on that site, but better would be is just update the ACL.
The answers are definitely RFC1918's but they're still not considered as rebind. Do you know why? Of course, I want rebind protection to work.
And how do I set the domain to private in the unbound that's doing the query?
For the unbound ACL where I'm forwarding to, if I update its ACL to allow the query from the unbound that's doing the query, what source IP will I put there if I don't do sourceNAT? If I don't do sourceNAT, I won't know what the source IP of the unbound from either side because IIRC the source for unbound requests is "This Firewall" and I'm not 100% sure what that is but that's the one in my SNAT rule now and it works.
-
@kevindd992002 said in DNS Resolver domain override issue for just one client in the same network:
RFC1918's but they're still not considered as rebind. Do you know why? Of course,
Did you set them as private in the unbound config? I guess there could be some config that says anything home.arpa the like could be non rebind, but I doubt that..
Did you turn off rebind completely?
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
edit
As to what IP.. With default outbound nat on, it would be the query unbound pfsense IP on the tunnel network you have setup for the s2s I would believe.. If you have messed with outbound nat from auto. It would have to be an IP that pfsense could use to talk to this other network with.. That would have to be the IP it has on the s2s connection. Or it would have to be natted to that IP, etc. -
@johnpoz said in DNS Resolver domain override issue for just one client in the same network:
@kevindd992002 said in DNS Resolver domain override issue for just one client in the same network:
RFC1918's but they're still not considered as rebind. Do you know why? Of course,
Did you set them as private in the unbound config? I guess there could be some config that says anything home.arpa the like could be non rebind, but I doubt that..
Did you turn off rebind completely?
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
edit
As to what IP.. With default outbound nat on, it would be the query unbound pfsense IP on the tunnel network you have setup for the s2s I would believe.. If you have messed with outbound nat from auto. It would have to be an IP that pfsense could use to talk to this other network with.. That would have to be the IP it has on the s2s connection. Or it would have to be natted to that IP, etc.I did not:
-
@kevindd992002 ha - they seemed to have changed it to help users doing local forwarding.
I just added a couple of test domain forwards for testing to a local ns.. And look what gets added to the conf ;)
I do not recall seeing this in the release notes? But there it is.. look in your
[21.05.1-RELEASE][admin@sg4860.local.lan]/: cat /var/unbound/unbound.conf
I wonder when that got added - I am pretty freaking sure it didn't use to do that..
edit: Well F me - looks like that was added sometime back in 2017 from looking through the github code for unbound.inc..
-
@johnpoz said in DNS Resolver domain override issue for just one client in the same network:
@kevindd992002 ha - they seemed to have changed it to help users doing local forwarding.
I just added a couple of test domain forwards for testing to a local ns.. And look what gets added to the conf ;)
I do not recall seeing this in the release notes? But there it is.. look in your
[21.05.1-RELEASE][admin@sg4860.local.lan]/: cat /var/unbound/unbound.confI wonder when that got added - I am pretty freaking sure it didn't use to do that..
edit: Well F me - looks like that was added sometime back in 2017 from looking through the github code for unbound.inc..
Lol, that makes total sense th!en. Thanks for the help!
