DNS not resolving and no changes made to cause issue
I have 2 setups for pfsense. The main setup is running as a VM on my unraid server. The backup is running on a Dell Optiplex. Because of issues with one interface, I had to shutdown the main server and start the backup. They both run the same configuration file. Last night, it was working no problems. When I woke up this morning, I was unable to resolve DNS. pfsense uses is using DNS resolver. I thought it was pihole, so I shut it down. I still had the same issue. I can ping addresses from terminal, but I cannot resolve an nslookup from terminal. Going back to my main pfsense on unraid, all works well. There is nothing different between the 2 other than hardware. What could have caused this problem, and how do I resolve it?
pfsense uses is using DNS resolver. I thought it was pihole,
So your client asks pihole, who then asks pfsense, who then resolves?
So you shut down pihole, and are asking pfsense directly now? Or you have both pihole and pfsense IPs listed in your client for NS?
On pfsense is unbound running? Can it do a query for something in diag, dns lookup.
Not sure what your "other" system has to do with anything - its just fluff info that provides nothing as far as info to solve the issue at hand.
Yes to point 1.
Yes to point 2 being shut down, and yes to both the pihole ip and pfsense ip for dns
Unbound is running, and I cannot resolve DNS through diagnostics or terminal. Pinging IP addresses works or at least googles 220.127.116.11 nameserver.
The only reason I mentioned the other environment is the configs are exactly the same. If it adds nothing to the discussion, the so be it.
yes to both the pihole ip and pfsense ip for dns
That is issue waiting to happen... You can never tell which NS a client will ask.. So if you have pihole and pfsense both listed.. If pihole is blocking something, and pfsense not - then you have problem if client asks pfsense.
"DNS through diagnostics or terminal."
Well what does the unbound log say about your query? UP the log level - if its actually running.. What error do you get when you try and do a dns lookup in the gui? What happens?
What does your dns status show? It should show you all the NS its talked to that are in its cache, etc. you should not see any timeouts, etc. etc..
example here is part of mine
Regarding pihole, it's been working for the past 6 months. I don't understand what would get it to change. In the DNS section of my DHCP server, I had the first listed as 10.10.x.5 for pihole and 10.10.x.1 as the second for pfsense in case pihole had issues. I'm not sure why all of a sudden that would block queries. Also, I took out the entries and refreshed dhcp at the computer to remove that obstacle. So my computer only got pfsense. Going forward, are you just saying to list pihole?
I decided to try something. I stopped dns resolver and used dns forwarder using 18.104.22.168 in the general setup section for my dns. It started to work. Then I reverted back to dns resolver, and all is working now.
This is rather confusing. I don't know what changed overnight.
No I think you misunderstand its not that you are using pihole and pfsense... The problem is you can not have the client point to both of them... Since you can never be sure which one the client will ask..
Say he asking about www.adserver.com so browser can show the ad.. If he asks pihole, he doesn't get get the ad.. But if the client for whatever reason asks pfsense it would just look it up and you would get the ad.
Not a big deal if just an ad, but what if malware that pi would of blocked..
pihole would not even ask pfsense for something that is in his block lists.. So pfsense would never be asked to lookup adserver.com
Clients need to point to NS that will answer in with the same stuff. If the NSes you list on the client will not return the same stuff, then only point to 1..
Its possible that unbound wasn't actually working? Even though it said the service was running.. Had you tried to just stop and start the unbound.. You could look at the info, you could look at the logs and sniff even on the wan to validate if was actually working to figure out why it wasn't resolving.