This bug is still present in 2.4.4-p3 (and possibly 2.4.5-p1, 2.5.0) and was frustrating to track down today.

Seems like the problem has 2 potential fixes:

make sure the contents of /var/unbound/dhcpleases_entries.conf is 100% cleared when the "Register DHCP leases in the DNS Resolver" checkbox feature is disabled.

or

when said checkbox is cleared, comment out the include: /var/unbound/dhcpleases_entries.conf line in /var/unbound/unbound.conf

I feel like #2 is the better fix, since that way DHCP leases would resolve properly if somone toggles the box off & then back on by mistake.

@Gertjan

Thanks, the file situation is solved.

On Telegraf unbound plugin with the conf file as it is with cumulative = no (changed in the inc file), it still doesn't respect the setting. So, it is not using the conf file in its default location or it's using status_noreset. How do I know which is the case ?

@Gertjan said in Resolve hostname stop working randomley on diffrent hosts:

But what do you mean with :
@avsion said in Resolve hostname stop working randomley on diffrent hosts:

upload XML hostnames.

Before reset to factory default i backup the resolver that includes all the manual hostname data entries.

@Gertjan said in Resolve hostname stop working randomley on diffrent hosts:

IMHO : UPNP should be avoided at all time. As you have to fully trust your devices .... and the entire Internet seeing them. You're right : put these on a seperate LAN - OPTx network.

Agree will disable UPnP. IoT is already on a separted VLAN with all firewall rules blocking access to LAN.

Thank you for your help, i will monitor the system and see how we go

@doktornotor Thank you, this was very helpful!
My OpenVPN clients couldn't reach my nginx reverse proxy despite the general NAT reflection policy (System > Advanced > Firewall & NAT), which worked just fine from the LAN.
So I was just about to follow the officially recommended split DNS way and enter a bunch of host overrides in Services > DNS Resolver, when I found your wonderfully elegant solution!

Route 53 DDNS update have stopped working for me too Here is a post I made on Reddit r/PFSENSE. I got no replies there, so posting here as a reply in the hope that this will be worthy of someone's attention.

=====

When doing DDNS updates, the log says:

Jun 21 00:37:42 php-fpm 703 /services_dyndns_edit.php: Curl error occurred: Failed to connect to route53.amazonaws.com port 443: Operation timed out Jun 21 00:37:42 php-fpm 703 /services_dyndns_edit.php: Dynamic DNS route53 (xxx.xxx.net): _checkStatus() starting.

To debug this, I noticed that earlier in the log, it showed the URL it was going to use for the update:

Jun 21 00:36:27 php-fpm 703 /services_dyndns_edit.php: Sending request to: https://route53.amazonaws.com/2013-04-01/hostedzone/--zoneID--/rrset

So I tried a curl to that url from the pfSense command line -- worked fine. So no idea why the connect is failing. Incidentally, I have no IPv6 enabled on the box. The aws log shows the last successful update was about 45 days ago, I think when I was still on 2.4.4 which is why I'm worried this might be a 2.4.5 or 2.4.5-p1 bug.

UPDATE:
This appears to be related to routing, please see further info in the related post just made in the routing area

@mcury Thanks for thinking along. I had already disabled that feature a while back. One of our DHCP clients was requesting a new lease every 2 seconds (ignoring the lease time) which already caused a lot of DNS resolver issues in the past. Here is the current DNS Resolver config:

pfSense0.JPG
pfSense.JPG

To be honest, without DNSSEC, without DHCP DNS registration, without IPv6 - this is like the most basic configuration you could possibly come up with for a DNS server. The fact that pfSense does not get this working properly has been cause of regret of purchasing an SG-3100 for months already. I really, really, really hope this DNS Resolver gets more stable & functional ASAP. The whole point of using DNS Resolver was moving our DNS server away from our Synology NAS to a "SMB grade network device" 😒

I'm glad I'm not the only one. I thought I was going crazy this morning. I applied the update a couple of days ago and all went fine. This morning after making one firewall rule change, I had issues resolving DNS. I use DNS-over-TLS and only when I toggled (Unchecked & saved - Rechecked & saved) the "Use SSL/TLS for outgoing DNS Queries to Forwarding Servers" under the DNS Resolver settings, did it start resolving properly. Very strange.

Out of curiosity on my part, why would you want to do this?

👍

One question down.

Two more to go.

@andrema2 said in Unbound Resolver low cache hits:

I'm at the same side you are.

Let's hope someone can pick this issue and somehow solve it.

Thanks anyway

Yep! I worked for many years in Information Technology at a large US Fortune 500 company. We were a Windows shop, so we didn't have the unbound issue. We named our employee desktop machines with the login ID of the assigned employee and a number tacked onto the end. That made it easy for the Help Desk to find a machine for RDP connections. You asked the employee their login ID and then you had their machine name. For shared computers, we had a slightly different naming scheme.

Yes, you are right. Stats are looking better and better. Also www.google.com already hit the cache. Thank you for helping.

Probably : the outgoing interface used by unbound to access 8.8.8.8 vanished ....

Found that a) the options need to be set in bytemasks ie 78 needs to be 05 01 AC 10 00 53 (length, boolean, IP of server) and 79 needs to be 0A 01 42 48 5E 2D 53 43 4F 5D 45 (length, boolean, name of scope) for it to work, and b) turn DHCP server off on the failover machine. There seems to be a bug when CARP is enabled that the second DHCP server will return garbage instead of what's configured in the SLP options.

I got past it somehow. I "think" either messing with /root/.profile or a reboot fixed it.

@bcruze thanks!

@bmeeks Thank you, I will research that distinction. Based on your brief description, I think I was simply using the wrong term for what I wanted unbound to do! I am still very new to DNS and have tried to stay with the stock settings as much as possible, except for what is necessary for PFblocker. Thank you again for your input!