Unbound Fails After Changes Applied
-
I recently replaced a VMware pfSense VM with a SG-3100 appliance. On the SG-3100, whenever configuration changes are made to Unbound, it stops resolving queries from nodes on the network. I have not found a way to restore functionality without rebooting the firewall. When testing DNS lookup from the web interface, it resolves everything correctly. All lookups from Windows nslookup return a "Query refused" error.
Any help on this would be appreciated.
-
What shows up in the resolver log when it fails?
Is the service running? -
The service remains running, but I have not been able to identify anything in the logs previously. I'll post a log sample this evening, when I can reboot the appliance without impact.
Another note, the problem occurs on a fresh factory image/configuration on this SG-3100. I'm going to rebuild a VMware VM and see if I can reproduce the issue, so I can try to determine if it is specific to the hardware or a more general issue.
-
It isn't a general issue as it works fine here on all my systems, including two SG-3100s. It must be something specific to your configuration or environment.
Do you have any packages installed, such as pfBlockerNG?
-
I have pfBlockerNG installed now, but I had tested the firewall with a factory default configuration on Saturday and ran into the same issue. The only configuration changes were to set my IP addresses. Once the IP addresses were set, I changed the System Domain Local Zone Type from Transparent to Type Transparent (because that should be an impact-less change), applied that change, and then resolution stopped working. I reverted the change and resolution still did not work. I have not been able to find a way to get it working again without a reboot. This was the same behavior I observed before rebuilding.
The consistent variables are the Cisco switch I'm uplinking to and the SG-3100 hardware. I can rule out the Cisco switch tonight.
-
The only log entries when the issue occurs are this.
Mar 4 18:09:20 unbound 41588:0 notice: init module 0: validator
Mar 4 18:09:20 unbound 41588:0 notice: init module 1: iterator
Mar 4 18:09:20 unbound 41588:0 info: start of service (unbound 1.8.1).The same issue occurs when connected directly to the 4 port switch, so the Cisco switch can be ruled out, as well.
-
@trippsc2 said in Unbound Fails After Changes Applied:
The only log entries when the issue occurs are this.
Mar 4 18:09:20 unbound 41588:0 notice: init module 0: validator
Mar 4 18:09:20 unbound 41588:0 notice: init module 1: iterator
Mar 4 18:09:20 unbound 41588:0 info: start of service (unbound 1.8.1).Disable DNSBL or pfblockerNG, then see if the DNS resolver is functionnal.
DNSBL can use a lot of memory, and I experienced a similar issue after Hitting the Apply button in DNS Resolver settings. Unbound need to be kill -9 in order to start it from the Services / Status tab.
Monitor the memory usage with Status / Monitoring.
-
The issue occurred before pfBlockerNG and DNSBL were installed. I disabled them to provide the logs in your quote and still reliably reproduce the issue.
-
@trippsc2 said in Unbound Fails After Changes Applied:
I recently replaced a VMware pfSense VM with a SG-3100 appliance. On the SG-3100, whenever configuration changes are made to Unbound, it stops resolving queries from nodes on the network. I have not found a way to restore functionality without rebooting the firewall. When testing DNS lookup from the web interface, it resolves everything correctly. All lookups from Windows nslookup return a "Query refused" error.
Any help on this would be appreciated.In the pfSense General tab, what did you select for the DNS servers? If you selected external servers, then pfSense itself will use those DNS Servers. Your LAN devices will then goto the pfSense Resolver for DNS resolution. Then if its in "Forwarder" mode, it will use the DNS Servers in the General tab. If its set to "Resolver" mode, then it will use the Root Servers for DNS resolution.
If you are using it in "Forwarder" mode, ensure that the Forwarders support DNSSEC.
Also increase the "Log Level" setting in the pfSense Resolver to "2" and then review the Resolver.log
-
I supplied no DNS servers, as I want to use root servers for resolution.
I'll increase the log level and reproduce issue and post the results either tonight or tomorrow night.
