DNS Issues After Upgrading to 25.07
-
-
@smsigroupit said in DNS Issues After Upgrading to 25.07:
how to do dig test and nslookup test while resolving?
As shown above. See my second post.
Also run this command on the command line (console or SSH, menu option 8 )
grep 'info: start' /var/log/resolver.logthis shows you how often the resolver (re) starts.
A restating resolver can't resolve ;)
That said, a restart typically uses a couple of seconds.@smsigroupit said in DNS Issues After Upgrading to 25.07:
The only change made was switching DNS-BL mode to Python mode, which resolved the issue.
Yeah, that one pops up all the time now.
The new way how KEA transmits leases into the DNS (unbound) is by parsing the actual unbound local cache, and inserting only new DNS info, and removing old lease info.
If the old classic pfBlockerng DNSBL method is uses (= one big file with all the DNSBL info in one go) this cache can become very big. Unbound will also take a lot of time to read and parse this file on every startup. During this startup, DNS doesn't work.
That's one of the reason the python mode was invented : it's better faster and asks less resources.
I really thought everybody wanted that, and everybody who was using pfBlockerng and DNSBL, was using python mode by now. Apparently ... not everybody. Anyway, you solved that now. -
grep 'info: start' /var/log/resolver.log
Aug 11 00:55:11 shoemakersfw unbound[29460]: [29460:0] info: start of service (unbound 1.23.0).
Aug 11 06:39:58 shoemakersfw unbound[10691]: [10691:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:03 shoemakersfw unbound[10691]: [10691:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:08 shoemakersfw unbound[10691]: [10691:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:14 shoemakersfw unbound[10691]: [10691:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:22 shoemakersfw unbound[42672]: [42672:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:28 shoemakersfw unbound[55348]: [55348:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:33 shoemakersfw unbound[55348]: [55348:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:46 shoemakersfw unbound[55348]: [55348:0] info: start of service (unbound 1.23.0).
Aug 11 06:40:55 shoemakersfw unbound[55348]: [55348:0] info: start of service (unbound 1.23.0).
Aug 11 06:41:00 shoemakersfw unbound[55348]: [55348:0] info: start of service (unbound 1.23.0).
Aug 11 06:43:07 shoemakersfw unbound[61105]: [61105:0] info: start of service (unbound 1.23.0).
Aug 11 06:44:40 shoemakersfw unbound[29989]: [29989:0] info: start of service (unbound 1.23.0).
Aug 11 06:44:58 shoemakersfw unbound[29989]: [29989:0] info: start of service (unbound 1.23.0).
Aug 11 06:45:21 shoemakersfw unbound[16934]: [16934:0] info: start of service (unbound 1.23.0).
Aug 11 06:45:26 shoemakersfw unbound[16934]: [16934:0] info: start of service (unbound 1.23.0).
Aug 11 06:47:00 shoemakersfw unbound[38812]: [38812:0] info: start of service (unbound 1.23.0).
Aug 11 06:47:06 shoemakersfw unbound[38812]: [38812:0] info: start of service (unbound 1.23.0).
Aug 11 06:47:13 shoemakersfw unbound[2075]: [2075:0] info: start of service (unbound 1.23.0).
Aug 11 06:47:18 shoemakersfw unbound[2075]: [2075:0] info: start of service (unbound 1.23.0).
Aug 11 13:19:57 shoemakersfw unbound[61466]: [61466:0] info: start of service (unbound 1.23.0).
Aug 11 13:20:03 shoemakersfw unbound[61466]: [61466:0] info: start of service (unbound 1.23.0).
Aug 11 13:26:19 shoemakersfw unbound[37451]: [37451:0] info: start of service (unbound 1.23.0).
Aug 11 13:26:25 shoemakersfw unbound[37451]: [37451:0] info: start of service (unbound 1.23.0).
Aug 11 13:26:49 shoemakersfw unbound[64440]: [64440:0] info: start of service (unbound 1.23.0).
Aug 11 13:26:56 shoemakersfw unbound[64440]: [64440:0] info: start of service (unbound 1.23.0).
Aug 11 13:45:50 shoemakersfw unbound[41576]: [41576:0] info: start of service (unbound 1.23.0).
Aug 11 13:46:33 shoemakersfw unbound[90435]: [90435:0] info: start of service (unbound 1.23.0).
Aug 11 13:48:57 shoemakersfw unbound[90435]: [90435:0] info: start of service (unbound 1.23.0).
Aug 11 13:57:33 shoemakersfw unbound[40816]: [40816:0] info: start of service (unbound 1.23.0).
Aug 11 13:57:33 shoemakersfw unbound[40816]: [40816:0] info: start of service (unbound 1.23.0).
Aug 12 00:03:21 shoemakersfw unbound[4089]: [4089:0] info: start of service (unbound 1.23.0).
Aug 12 00:04:11 shoemakersfw unbound[4089]: [4089:0] info: start of service (unbound 1.23.0).
Aug 12 06:27:26 shoemakersfw unbound[4089]: [4089:0] info: start of service (unbound 1.23.0).
Aug 12 06:27:33 shoemakersfw unbound[52402]: [52402:0] info: start of service (unbound 1.23.0).
Aug 12 06:27:39 shoemakersfw unbound[52402]: [52402:0] info: start of service (unbound 1.23.0).dig cnn.com +trace
; <<>> DiG 9.20.6 <<>> cnn.com +trace
;; global options: +cmd
. 57054 IN NS g.root-servers.net.
. 57054 IN NS h.root-servers.net.
. 57054 IN NS i.root-servers.net.
. 57054 IN NS j.root-servers.net.
. 57054 IN NS k.root-servers.net.
. 57054 IN NS l.root-servers.net.
. 57054 IN NS m.root-servers.net.
. 57054 IN NS a.root-servers.net.
. 57054 IN NS b.root-servers.net.
. 57054 IN NS c.root-servers.net.
. 57054 IN NS d.root-servers.net.
. 57054 IN NS e.root-servers.net.
. 57054 IN NS f.root-servers.net.
. 57054 IN RRSIG NS 8 0 518400 20250824200000 20250811190000 46441 . Ch2FL9ZmmZExl/aFERtrjuInzUz1gfMiVPS3jsoz3PBaNmKS50N/dfFq 5R2Irct7wBLVAHdgKKFjPvTSFSrznKZSKPg4muqMsS4+CJ55di/GUNhh lSCOp6ZBElRqfPTM464L2wDSaTn6JQ6ZICxrIAPaBPjdKLIE8kVY6XJP wq5RsTCUXUnEkZEmanLLOiAMaNHTIAZ83nSiyraQ0rTG8rbvcooHA54C FU7B9MLpCnDVII/qUYb/M/lqFYSoi3uobopqwTnhYnlwfF62Ao/K6LC/ +eMguMIfLJ5rs+8C/8EYZtzmJPPAGNaK/FFq19mRbKMQ0ZleX/7clH5+ b4PgTg==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms;; UDP setup with 2001:500:12::d0d#53(2001:500:12::d0d) for cnn.com failed: host unreachable.
;; no servers could be reached
;; UDP setup with 2001:500:12::d0d#53(2001:500:12::d0d) for cnn.com failed: host unreachable.
;; no servers could be reached
;; UDP setup with 2001:500:12::d0d#53(2001:500:12::d0d) for cnn.com failed: host unreachable.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com. 86400 IN RRSIG DS 8 1 86400 20250825050000 20250812040000 46441 . DVTu+B/+DFQ/7N53YKXuJdaUtPomtpmH9++OS2K5Z4xf2SGpVuwZi4H8 47FmcUFd68+sXU61DCEj+jYMPKUsQYbr8ymtXZMSpC/9NRV2BQn+1D7E KhAMMPU/ltt14DU0j0+hYt2p6ABoSy9FpNaCLvfjwnKPMApf5jYpzFfD FmM6Q5PpQNthq2mKmBcJWZjuTvA32Iys15nJot+Zg1tcVD88T03Wm+F8 ojU0ecjCU+1U28GgibVuhCMZwDKzhNI83a2Cetdxi7hKyYQllnpq/SOt PLTmgqPkZk6w5NS9csKycoXyolW0UFNGVV6osjGUE1FIiA0LRUDoYEC2 7X4R6Q==
;; Received 1167 bytes from 170.247.170.2#53(b.root-servers.net) in 47 mscnn.com. 172800 IN NS ns-587.awsdns-09.net.
cnn.com. 172800 IN NS ns-378.awsdns-47.com.
cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk.
cnn.com. 172800 IN NS ns-1242.awsdns-27.org.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250819002508 20250811231508 20545 com. IgcCaCYvFc9ADNjiGojHLa7mrwCn9mzzwOxHxHdhhypOuigpHPHtbgA2 CoMOVJ38n57s7Kkh7iP2/fdKRX9Shg==
FVT7IKJ9C0BTF07HNDO4FLBRB7D7NCL2.com. 900 IN NSEC3 1 1 0 - FVT7K43DJ0K7KJ384M71US54D3690VUI NS DS RRSIG
FVT7IKJ9C0BTF07HNDO4FLBRB7D7NCL2.com. 900 IN RRSIG NSEC3 13 2 900 20250816012853 20250809001853 20545 com. 0afRonASH5vKKxyBxzPqwOS3DMKhEpoCuBnWuKh4qCeSlaa5xA2YZpHz y/wj2VEI7qXN2PQQCLJD64EH1P74eg==
;; Received 546 bytes from 192.31.80.30#53(d.gtld-servers.net) in 205 ms;; UDP setup with 2600:9000:5304:da00::1#53(2600:9000:5304:da00::1) for cnn.com failed: host unreachable.
;; UDP setup with 2600:9000:5306:7400::1#53(2600:9000:5306:7400::1) for cnn.com failed: host unreachable.
cnn.com. 60 IN A 151.101.131.5
cnn.com. 60 IN A 151.101.3.5
cnn.com. 60 IN A 151.101.195.5
cnn.com. 60 IN A 151.101.67.5
cnn.com. 172800 IN NS ns-1242.awsdns-27.org.
cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk.
cnn.com. 172800 IN NS ns-378.awsdns-47.com.
cnn.com. 172800 IN NS ns-587.awsdns-09.net.
;; Received 237 bytes from 205.251.194.75#53(ns-587.awsdns-09.net) in 27 ms; <<>> DiG 9.20.6 <<>> cnn.com +trace +nodnssec
;; global options: +cmd
. 56974 IN NS f.root-servers.net.
. 56974 IN NS g.root-servers.net.
. 56974 IN NS h.root-servers.net.
. 56974 IN NS i.root-servers.net.
. 56974 IN NS j.root-servers.net.
. 56974 IN NS k.root-servers.net.
. 56974 IN NS l.root-servers.net.
. 56974 IN NS m.root-servers.net.
. 56974 IN NS a.root-servers.net.
. 56974 IN NS b.root-servers.net.
. 56974 IN NS c.root-servers.net.
. 56974 IN NS d.root-servers.net.
. 56974 IN NS e.root-servers.net.
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for cnn.com failed: host unreachable.
;; no servers could be reached
;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for cnn.com failed: host unreachable.
;; no servers could be reached
;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for cnn.com failed: host unreachable.
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for cnn.com failed: host unreachable.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
;; Received 860 bytes from 192.36.148.17#53(i.root-servers.net) in 34 ms;; UDP setup with 2001:502:8cc::30#53(2001:502:8cc::30) for cnn.com failed: host unreachable.
cnn.com. 172800 IN NS ns-587.awsdns-09.net.
cnn.com. 172800 IN NS ns-378.awsdns-47.com.
cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk.
cnn.com. 172800 IN NS ns-1242.awsdns-27.org.
;; Received 189 bytes from 192.5.6.30#53(a.gtld-servers.net) in 207 ms;; UDP setup with 2600:9000:5306:7400::1#53(2600:9000:5306:7400::1) for cnn.com failed: host unreachable.
cnn.com. 60 IN A 151.101.131.5
cnn.com. 60 IN A 151.101.67.5
cnn.com. 60 IN A 151.101.3.5
cnn.com. 60 IN A 151.101.195.5
cnn.com. 172800 IN NS ns-1242.awsdns-27.org.
cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk.
cnn.com. 172800 IN NS ns-378.awsdns-47.com.
cnn.com. 172800 IN NS ns-587.awsdns-09.net.
;; Received 237 bytes from 205.251.196.218#53(ns-1242.awsdns-27.org) in 26 ms -
About the (restarts) :
Check with the system log what happened, why unbound was told to restart.
A very common reason is : an interface used by unbound was taken down for a moment.
If possible, stop this from happening.About the dig : dig bypasses the resolver (unbound), it does all the work 'itself'.
As it get back DNS records with IPv6 addresses, it will use these to 'check' them. Because your don't have Ipv6 support, these will fail.A cleaner result can be obtained by specifying dig to use IPv4 only :
dig -4 cnn.com +traceBut dig isn't the resolver.
There are special options for unbound that you can specify here :
so you can inform unbound not to use Ipv6 (just to be sure).
-
-
-
Thank you for your assistance. I will continue to monitor the system status.
-
Been seeing a similar issue after upgrading to 25.07. Internal resolver just stops working completely at random and can't recover on its own. Never had issues with this on 24.11, and no package changes or settings changes. Restarting unbound doesn't even fix it most of the time; I have to resort to allowing DNS to fall back to remote servers to get it working again. Nothing interesting in the logs other than failed DNS resolutions and an occasional restart message. Even trying to ping google.com from the UI fails until I've toggled the DNS fallback behavior (which shouldn't be a thing given that my DNS setup is effectively a mirror of https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html). In my case DHCP is disabled and pfBlocker is in Python mode so no DHCP issues should be at play here. Sounds like there's a nasty bug floating around but not really sure where to look in logs and filing a bug with no supporting information other than 'it's not working' doesn't seem productive. In the meantime, I'm just glad I no longer use pfSense for my DNS because it's unreliable after this upgrade.
-
@freph533 said in DNS Issues After Upgrading to 25.07:
In my case DHCP is disabled
So all your LAN devices have a static IP, network, gateway and DNS set.
DNS points to where - what IP ?If 'unbound' (the resolver) had a problem, this forum would 'explode' right now with hundreds of thousands complaining about DNS not working - you agree ?
Your pfSense resolver setup is not default, as you 1) forward, and 2) over TLS.
If you go back to default resolver mode, your issue is gone ?
You forward (over TLS) to where ?
Still, if unbound couldn't forward over TLS to, for example 1.1.1.1, then the https://github.com/NLnetLabs/unbound/issues would mention this.The bad and good news rule probably apply : it's your setup/connection/ISP ...
I've tested this https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html many times, (but not yet with the latest 25.07.1).@freph533 said in DNS Issues After Upgrading to 25.07:
Even trying to ping google.com from the UI
If DNS is down, google.com won't get resolved, and ping can't work. Ping needs an IP, not a host name.
If you were using an IP, ping would work, right ?@freph533 said in DNS Issues After Upgrading to 25.07:
and pfBlocker
I have to ask / check : pfBlockng isn't blocking the DNS server you forward to, right ?
-
@Gertjan said in DNS Issues After Upgrading to 25.07:
So all your LAN devices have a static IP, network, gateway and DNS set.
DNS points to where - what IP ?All of my clients point to an external DHCP/DNS server since I decided to decouple it from pfSense in case I ever wanted to switch to another firewall/router solution.
If 'unbound' (the resolver) had a problem, this forum would 'explode' right now with hundreds of thousands complaining about DNS not working - you agree ?
I agree - but there's a nonzero amount of reports of this issue. The hard part is correlating exactly what's scenarios cause it. I imagine pfBlocker and DNS over TLS usage is widespread enough that if it were linked solely to those common items it would be a much more reported issue, however that's not the case.
Your pfSense resolver setup is not default, as you 1) forward, and 2) over TLS.
It's not default, but it's a documented configuration published by Netgate themselves that should still be functional after an upgrade where it was previously working just fine on 24.11.
If you go back to default resolver mode, your issue is gone ?
Haven't tested disabling forwarding (DNS Query Forwarding under DNS Resolver) when this issue happens. I can try it and get back to you when it occurs again.
You forward (over TLS) to where ?
To Cloudflare. As I said, it's effectively a mirror of the DNS over TLS docs - Cloudflare IPv4/IPv6 and all.
Still, if unbound couldn't forward over TLS to, for example 1.1.1.1, then the https://github.com/NLnetLabs/unbound/issues would mention this.
I never said it had issues forwarding. It's the internal resolution that pfSense uses to resolve things for itself that fails. Toggling DNS Resolution Behavior to use remote for fallback instead of ignore remote gets it out of whatever weird state it's in when it breaks, and I can change it back to ignore remote servers (which is the desired setting and what's suggested to use in the DNS over TLS docs.
The bad and good news rule probably apply : it's your setup/connection/ISP ...
I've tested this https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html many times, (but not yet with the latest 25.07.1).This isn't related to ISP - this is an issue that explicitly started happening after the update. My other recursive DNS server that hits roots works just fine. And as mentioned it works fine for a while after it's been restarted/DNS behavior toggled. It's still working just fine after I restarted it last night. That's the problem - this happens seemingly at random.
If DNS is down, google.com won't get resolved, and ping can't work. Ping needs an IP, not a host name.
If you were using an IP, ping would work, right ?Yep - IP (and IP communications) continue to work just fine. It's pfSense's own resolution that breaks (and breaks domain resolution of aliases along with it which is problematic).
I have to ask / check : pfBlockng isn't blocking the DNS server you forward to, right ?
No.
One thing I noticed was that ntopng was taking up quite a lot of resources compared to normal so I disabled it and cleared out all of its data. I'll be interested to see if the issue with the resolver resurfaces again now that it's disabled.
-
Update from my side: issue hasn't appeared again since disabling ntopng, so seems that was the culprit (or one of them, anyway).
