DNS Forwarder Custom Options unreliable
-
I've used entries in the Custom Options section, for years, without any issue until recently. Currently on ver 2.5.2. I have an entry, example address=/abc.dynu.net/192.168.2.1, and it redirects one mobile phone to the Lan interface but doesn't redirect another mobile phone to the Lan but rather goes out the default Wan interface. Both phones are on the same WiFi SSID, same subnet and same Vlan. There are no rules specific to these two mobile devices. Any suggestions on where to begin troubleshooting this problem would be appreciated.
-
@markn6262 Are you trying to do a host override? There's a whole section for that, instead of using a custom option...
re: devices and DNS, many browsers and devices use DNS over HTTPS (DoH) and bypass local DNS servers by default, nowadays.
-
@steveits I wasn't, I was using custom options as mentioned. But if I remove the custom option line and put it in host override instead with "abc" as host and "dynu.net" as domain and the Lan gateway address I get the same results. One mobile device gets a reply to pings and routes from the Lan gateway and the other mobile device gets a reply from the Wan gateway. This is with both devices having WiFi enabled and Cellular disabled.
-
@markn6262 and as mentioned if your device is not getting what you put in, and others are - guess what its not using your dns..
-
@johnpoz Ok well thats easy to say, point at another cause. Besides both mobile devices using the same network, they also are being given DHCP and DNS addresses by the PfSense DHCP server. Looking at the phone settings they both have the same gateway and DNS address. The only difference is one has an IP address of x.x.16.3 and the other is x.x.16.4. So how then can one & not the other use x.x.16.1 gateway when both are set to that address? Should I do a comparative packet capture to prove my point? I haven’t heard any suggestions just assumptions.
-
@johnpoz When I do a Dns query using the same dns query tool, to the same hostname, asking from the same pfsense dns server address on both devices they both get the same response from the pfsense lan ip.
-
@johnpoz Then I put in the same http://hostname:port in the same browser or in the associated app, one device is redirected to the local server, by the host override, and I get the servers login screen. The other device gets “This site can’t be reached”.
-
@markn6262 browsers love to use Doh these days.. Not asking your dns.. They know better than you, and want your dns queries..
Turn off doh in your browser.
Unless you made significant effort to setup a view in unbound to return answer X for IP A, and Y for IP B anything that asks unbound for the fqdn you setup a host override for would get that answer. If your not, then its clear your not asking pfsense.
You proved that when you did a specific query, so your browser or application or device when not directed to do so via actual command is doing what it wants and asking something else, most likely via doh, and getting the actual public IP record for your fqdn.
-
@johnpoz No DoH enabled in my browser. I'll continue to pursue this with the app developer to see if they might be using DoH in one phone and not in the other even though both phones have the same app version.
-
@johnpoz Given your response and shifting my focus off the router, after several hours of trial'n'error changes I finally narrowed it down to one setting in the iOS device. In WiFi settings the "Limit IP Address Tracking" has to be disabled on the problem phone even thought it's enabled on the properly working iPhone. Go figure. Not sure why it's not consistent between devices or what this setting actually does to dnat, but it now works. Mystery not solved but fixed.
-
@markn6262 there is no mystery.. If you set unbound to answer X for some fqdn... It will answer X.. If your client doesn't get X back - then its 100% clear and easy to comprehend that client didn't ask unbound..
You could setup unbound to answer X vs Y depending on the IP asking - but that is a very involved setup with views, that you would be for sure you actually went through the steps to do. ;)
Why this was a question is where I have the mystery to be honest. If you set something to answer X and client A and client B, and even client C get back X.. But client D using something on the client gets back Y.. But when you directly ask it gets back X.. How would it be anything to do with pfsense or unbound??
-
@johnpoz I started this thread asking for any troubleshooting suggestions and all I got was defensive responses that PfSense is not the problem, my device setup is the problem. At this point in the thread we still don't know for sure which is the problem. I found a work-around and we'll leave it at that. Perhaps another may benefit from this thread if they run into this issue and try the setting that fixed the problem.
-
@markn6262 Not defensive just stating facts.. If you setup dns, any dns be unbound, be bind, be powerdns, be dnsmasq.. And you clients ask it and it gives the answer you put in. But then something else gets some other answer - then is blatantly obvious this other thing isn't asking it..
Unless you on purpose setup a view, which if you had - you would of known you did this.
Maybe you are just unaware of the goal of these apps and browsers and even OSes to bypass what you tell it to use for dns, and use them, or their partners via doh..
But you set something to give X back as an answer when you ask for some fqdn, and you don't get that answer - and other things that do get the answer you put in. Not sure what sort of snake needs to bite you on the nose for you to see that you didn't ask the thing you setup..
the first answer to you question telling you this
many browsers and devices use DNS over HTTPS (DoH) and bypass local DNS servers by default, nowadays.
You then stated
One mobile device gets a reply to pings and routes from the Lan gateway and the other mobile device gets a reply from the Wan gateway
This clearly shows that your whatever is not asking unbound.. If other devices that ask it get what you put in.
The is no need to "troubleshoot" your setup, if clients get what you put in, then what you put in is working. You can look around, this is not a uncommon issue where users whatever was using doh for the reason they were not getting the expected answer they put in.