DNS Resolver Refusing All Queries: host_entries.conf has local-zone: "." refuse set

Nimda_2025

Plea for assistance

99% through a deployment and think I may have stumbled upon a bug, or at least something I didn't discover in the Wiki, Google, Reddit, ChatGPT, or this forum (I swear, I searched).

Devices Specifics

Netgate 8200 running PFSense+ 24.11

Issue:

cat /var/unbound/host_entries.conf shows 'local-zone: "." refuse' on the first line. This is causing all queries sent to DNS Resolver to be refused (nslookup returns "interfaceip can't find google.com: Query refused)

I have no idea where this is coming from,

Attempts to Remediate:

comment out the line, returns after restarting DNS Resolver Service
Backup DNS Resolver to xml and review. Didn't see anything in there regarding a local-zone. restored backup and, restarted
Reviewed and changed domain listed on System\General Setup - was redacted.com is now tw.internal.redacted.com

Active Workaround:

Add this

server:
  local-zone: "." transparent

to the Custom options section of DNS Resolver. 'local-zone: "." refuse' is still in host_entries.conf, but this seems to have overridden it (thank goodness).

How did I cause this

I wanted the PFSense system to use different DNS servers than the DNS Resolver service uses for forwards. Why? I want the PFSense system itself to use several DNS servers for reliability and I wanted clients using the DNS Resolver service to use a DNS Filtering system. To do this I added

forward-zone:
  name: "."
  forward-ssl-upstream: no
  forward-addr: x.x.x.z
  forward-addr: x.x.x.x

to the Custom options section of DNS Resolver. I have since removed this customization. DNS resolution started failing shortly after this. I mention it because this is the only time I used root (.) in configuring this firewall.

Gertjan

@Nimda_2025

?

Try the default setting, static or transparent.

edit :

@Nimda_2025 said in DNS Resolver Refusing All Queries: host_entries.conf has local-zone: "." refuse set:

I want the PFSense system itself to use several DNS servers for reliability

Unbound, the Resolver, already uses world's best "13" DNS servers. With these "13", the Internet would stop working within minutes. Guess what : afaik, that never happened.

Nimda_2025

Thanks for the reply.

regarding the system domain local zone type;

My local domain is not root (.)
my firewall is/was been set to "transparent". I tried toggling this setting to refuse and back to transparent just to see if that might shake it loose. didn't help.

Regarding Unbound using 13 DNS Servers: Because I need unbound to use DNSFilter to provide results to my clients, and thus reducing reliability. I want to ensure that if DNSFilter has a bad day, the firewall continues to function properly (connecting to central management, resolving aliases, renewing certificates, etc). I am not trying to make unbound more reliable, I am making it less reliable and am trying to mitigate that choice.

Gertjan

@Nimda_2025 said in DNS Resolver Refusing All Queries: host_entries.conf has local-zone: "." refuse set:

Because I need unbound to use DNSFilter

In that case :
Forward to one, or a set of DNS (resolver or not) that to the filtering. For example 1.1.1.1 or OpenDNS The latter has a GUI where you can set what kind of host names you don't want to be resolved for your (network).
and / or (you can use both)
Use a local DNS filter like pfBlockerng for pfSense. Unbound can still be in the default resolving mode. Unbound will still resolve the requested host name, but, before it goes ouit and resolves, it will compare the requested host name with forbidden 'DNSBL' = DNS Black List. If a match is found, "0.0.0.0" will be returned, which means : "ok, sorry, I can't give you an IP for the requested host name."

Nimda_2025

Solved!

While I'm not certain how this was caused, I can say how it was resolved (with the help of Netgate support). After about a dozen back and fourths with NG Support, the culprit in the overall XML config was this snippit of XML

<strictout></strictout>

Edit File: https://docs.netgate.com/pfsense/en/latest/config/xml-configuration-file.html#edit-in-place and delete the XML line above.
Clear Config Cache: Diagnostics>Command Prompt rm /tmp/config.cache
Restarted DNS Resolver/unbound

and I was off to the races.

Hope this helps someone else.

johnpoz

@Nimda_2025 said in DNS Resolver Refusing All Queries: host_entries.conf has local-zone: "." refuse set:

I want the PFSense system itself to use several DNS servers for reliability

I know you have fixed whatever issue you were having - but this got me curious.. What do you think pfsense even really needs dns for exactly? It does dns query to find out where to go to check if there is an update. To load the packages list, where to store your backup..

You think using roots is less reliable than some other dns service - which you maybe don't understand use the roots as well.. As @Gertjan mentions.

In simple terms all googledns is like a copy of unbound they run, oh they have lots of servers lots of connections - and all over the globe via anycast to get to them, etc.. But at some point their system has to talk to the roots an well, and then gltds and then the authoritative ns for whatever your looking up..

Pointing to multiple dns out on the internet for reliability just doesn't really make a lot of sense, especially since to be honest dns could be down for pfsense itself for a days and you prob wouldn't even know - other than the gui might be slow to respond.

I can tell you for one thing - even if your dns was down, you would know it much sooner on your actual clients using unbound on pfsense, then if pfsense itself couldn't resolve something.

All the dns services on the planet could go down for their own reasons.. And roots would still be available - if the roots are down - the internet is down.. Doesn't matter which dns service you forward too.

Nimda_2025

@johnpoz

I think where folks are misunderstanding me is the word reliability.

I'm using DNS filtering for client lookups, via a particular vendor, a service I pay for. It's like OpenDNS/Umbrella but a different vendor. I would rather my clients be without Internet than without its protection. The two most common failures I've experienced is 1. Just a run of the mill outage and 2. False positive, which results in the wrong result being returned to a legitimate query. I can live with client devices having issues from time to time, but the impact to the firewalls and the management of the networks they protect would be much more severe.

I use aliases, and url lists quite a bit, the firewalls VPN back to a central service for management. I run comparative diagnostics from these firewalls as well. All require clean DNS results.

I usually use forwarders because a long time ago I heard it was "bad form" to use root servers unless you had to (putting additional load on systems when not needed).

I agree, root name servers, or forwarders, it doesn't really matter from an "is upstream DNS working", but like I said that's not the the problem I'm trying to solve.

Alllllll that being said, it all works, clients get filtered sanitized DNS results, and the firewall gets unadulterated DNS results ensuring management and aliases resolve as intended.

Hope this clears things up.

johnpoz

@Nimda_2025 so you think this filtering service would be filtering the handful of things pfsense needs to do a dns query for? If so turn them in to get whitelisted..

Like I said the only thing pfsense needs dns for is a handful of fqdn. The only real other pfsense uses dns for is resolving the PTR of IPs in the firewall log when you tell it to do so by clicking the little i next to the IP.. Why would a filtering service be blocking ptr lookups?

I don't really see the point of jumping through any odd config setup to point pfsense to some different dns than your clients behind pfsense are using.

Nimda_2025

@johnpoz I have 1000's of domains in url aliases that are centrally managed via GitHub repo that I use across multiple firewalls, that I don't want subject to DNS filtering. These are going to be resolved by the firewall itself. How else would I do it? Whitelist where? It'd be way more maintenance to try and do this in the DNS filter itself.

I don't think this is complex (compared to known alternatives), the GUI accommodates this fine.

If there is a better way I'm all ears.

johnpoz

@Nimda_2025 doesn't matter if you have a million different domains.. Why would your filtering service filter the handful of fqdn that pfsense is going to be checking for - every single pfsense no matter what its domain name is is going to be looking for only a couple of fqdns in the same domain, ie acb.netgate.com is a fqdn it would need to resolve to send up the auto config backup it does.

Your firewall is not a browser..

Nimda_2025

@johnpoz every single PF sense except mine which looks up several thousand domains in aliases that are used in firewall rules.

Why would the DNS filter screw up my DNS lookups? I don't know, but it's a possibility, so I mitigated it.

johnpoz

@Nimda_2025 aliases having different results than what I client might want to go to is creating a problem, not fixing it.

But hey you do you..

Nimda_2025

@johnpoz

Creates what problem?

johnpoz

@Nimda_2025 So I want to filter xyz be it allow or deny.. And pfsense resolve 1.2.3.4, and client resolves 4.5.6.7 - your going to have a hard time your aliases doing what you want.

Be it client resolves some IP that sends them to a hey this is blocked IP or whatever.. If the client doesn't resolve xyz to anything because its filter.. why would pfsense even need to resolve it at all to put in a alias?

You have your pfsense resolving 1000's of fqdn every 5 minutes, which is what the default filtering service that populates aliases does.

Like I said you do you.. But having a hard time coming up with a scenario where pfsense would need to resolve something differently than a client.

Nimda_2025

@johnpoz Ahhhhhhhh. Gotcha. great point. Will have a re-think.

Thanks for sticking with me. Not sure what I'm doing is pointless, but hadn't really considered that, had tunnel vision.