Another LAN DNS resolution difficulty thread
-
DNS servers wouldn't be listed in that particular output. That's just showing default route info. To show dns servers, you have to
cat /etc/resolv.conf
. When I runnslookup
for a name, I just get asterisks.The odd thing, right now, is that I'm accessing things through my wireless router, and I only have 192.168.0.1 in
/etc/resolv.conf
. So I might not need help anymore! -
False alarm. I still need the google DNS server IPs pushed to DHCP clients.
-
DNS server settings are:
- Enable DNS server
- Respond to SSL/TLS requests
- Network Interfaces: LAN, LAN (IPv6), localhost
- Outgoing Interfaces: WAN, WAN (IPv6), localhost
- Enable DNSSEC support
DNS Server settings under "General" are:
- DNS Server IPs are 8.8.8.8 and 8.8.4.4 with gateway set to "none" for both
- Allow DNS server list to be overwritten by DHCP on WAN
-
I restarted unbound, and here's what the log says, although I'll need help in figuring out what to do:
https://pastebin.com/sNNScaS2
-
I thought resolv.conf only held static entries? If your clients are DHCP then dhclient.leases is usually where to look. I asked about that but you didn't address it.
Allow DNS server list to be overwritten by DHCP on WAN - you probably don't want this. If your WAN is also DHCP then your specified DNS will be replaced by your ISP DNS.
Those Unbound 'can't bind socket' errors look like you already have something listening on that address. You aren't also running DNS Forwarder or BIND, are you?
-
Hi @steve973
I think you need to decide first whether you want to use Unbound as a DNS resolver or just as a DNS forwarder. The setup slightly different for each:
A. Use Unbound as a DNS Resolver
- Make sure no additional DNS servers are entered under System --> General Setup
- Uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup
- Under Services --> DNS Resolver make sure DNSSEC is enabled, and "Enable Forwarding Mode" is disabled
- No need to check "Respond to incoming SSL/TLS queries from local clients" unless you actually have your clients setup to send DNS requests over SSL/TLS
- No need to select IPV6 under network interfaces unless you are actually using it on your LAN/WAN
- Make sure that under Services --> DHCP Server you are not overriding the DNS server settings manually.
- Make sure your clients are setup to obtain DNS server information as part of the DHCP request (i.e you are not manually overriding it in resolv.conf, etc.).
B. Use Unbound as a DNS Forwarder:
- Enter DNS servers you wish to use under System --> General Setup if you want to use DNS servers other than your ISP's. If you want to just the servers you entered (e.g. 8.8.8.8/8.8.4.4) be sure to uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup so that your ISP's DNS servers are ignored.
- If do you wish to use your ISP's DNS servers, make sure that "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup is checked.
- Under Services --> DNS Resolver make sure "Enable Forwarding Mode" is enabled.
Steps - Steps 4 - 7 from above remain the same.
Hope this helps.
-
For the people that participated in this thread to help me out, thank you very much for helping. I figured out the problem today. I have a tp-link archer c9 wireless router that was conflicting with the IP address of the netgate appliance. DNS queries were being intercepted by the wireless router, so when I was trying to use the recommended settings through pfsense and provide the appliance's lan address as the DHCP server, it was actually using the wireless router's DNS. So I have that fixed, and now everything is working perfectly!
For anyone who comes across this thread in the future, if you are having issues with DNS, and nothing seems to be working, then try removing your wireless router from the network and shut it down. If that fixes the problem, then you have a collision with your wireless router like I had.
-
To server as an explanation to the people who helped me, and for better information for anyone who comes through here with the same problem, here is some more information about exactly what was wrong:
- I have pfsense set up statically as 192.168.0.1 on the LAN port. Through DHCP, it serves up addresses in the 192.168.0.10 - 192.168.0.240 range.
- I have my tp-link router on the network, and it obtains an address via DHCP from the pfsense appliance. It was getting 192.168.0.11 at this time
- I had the LAN interface on the tp-link router set statically to 192.168.0.1. I am not sure why or how this was the case, since it worked with my old pfsense setup.
- Oddly enough, because these networks were separated through the tp-link router, there was not an actual conflict between the pfsense appliance and the wireless router.
- The pfsense appliance was providing DNS resolution, and the tp-link router was handing out 192.168.0.1 as the DNS server.
- For clients connecting via ethernet or wireless through the tp-link router, this was the IP of the tp-link router which does not provide DNS resolution.
Thus, DNS on the tp-link router's network would fail because the tp-link router did not route the DNS requests to the netgate appliance. Having the same IP address, even on different logical networks, prevented this. I am not sure if I could have set up a route that might have made this work, but it seems like a bad setup anyway.
I have moved the tp-link router to the 192.168.1.0 subnet, and it hands out addresses, via its DHCP server, in this subnet. Now 192.168.0.1 is unambiguous, and DHCP requests now route correctly.
-
Your tp-link should just be used an an AP - the router mode should b deactivated.
Give it a static IP like 192.168.0.2.
Shut down DNS shut down DHCP server and client.
If it has a RJ45 plug called WAN on it's back, don't use that one. Use a (the) LAN plug. -
@gertjan I don't necessarily agree, although your suggestion is reasonable for some use cases. There are many, many levels of NAT throughout the interconnected networks on the internet, and adding another level of NAT in my home is not a problem in and of itself. In fact, with the right routing table, the problem that I had would not have been a problem.